Possible Bug: Attaching a modifier to Reverb Time

philipacamaniac

Fractal Fanatic
I've encountered this in a few presets so I tried a blank slate to see what was really going on.

A preset with nothing in it, just a reverb block, uses about 24-37% depending on reverb settings.

Attaching any modifier (Scene Controller, External Controller, etc) to the Reverb Time causes the CPU to jump anywhere to 75%. High reverb times (even 100 seconds) do NOT cause the CPU to spike like this when set without a modifier. This renders Reverb Time useless with modifiers, for actual preset usage.

Hopefully this is just a bug that can be fixed, as I'm in need of building some presets where the reverb time can smoothly fade between long trails or short trails.
 
It's a known thing, not a bug. Recalculating Reverb requires a lot of CPU power.
 
Serious bummer. I may actually have to stick an H9 or Big Sky on the board and rethink some things. That was a primary use of mine with the M13 - I used an expression pedal to morph decay time / feedback and mix level on a number of reverbs and delays all at once. I was looking forward to scenes controlling this instead, but it looks like not even an expression pedal will work.

I'm going to wish list the ish out of this one.
 
It's a known thing, not a bug. Recalculating Reverb requires a lot of CPU power.

Sorry, but something doesn't seem correct with your explanation.

If you adjust the Reverb Time in AX8-Edit, it changes smoothly without any "zipper" noise or noticeable adjustment, and the CPU only jumps by 1%-3%. The CPU meter under Utility on the unit itself confirms this. Adjusting the Reverb Time, quickly or slowly, to short times or very long times, affects the CPU very little as the change is occurring. So recalculating reverb time isn't so intensive after all...



It reminds of the bug from awhile back where a modifier attached to the Input Drive on an amp would cause the CPU to skyrocket. That particular one turned out to be an actual bug and it was fixed.

Actually, after rebooting, I was able to attach Extern 1 to Reverb Time in a fresh preset, and it didn't do anything to the CPU. Then I took it off, and reattached it, and it jumped up to 79%. Something seems awry.
 
Sorry, but something doesn't seem correct with your explanation.

If you adjust the Reverb Time in AX8-Edit, it changes smoothly without any "zipper" noise or noticeable adjustment, and the CPU only jumps by 1%-3%. The CPU meter under Utility on the unit itself confirms this. Adjusting the Reverb Time, quickly or slowly, to short times or very long times, affects the CPU very little as the change is occurring. So recalculating reverb time isn't so intensive after all...



It reminds of the bug from awhile back where a modifier attached to the Input Drive on an amp would cause the CPU to skyrocket. That particular one turned out to be an actual bug and it was fixed.

Actually, after rebooting, I was able to attach Extern 1 to Reverb Time in a fresh preset, and it didn't do anything to the CPU. Then I took it off, and reattached it, and it jumped up to 79%. Something seems awry.


Yeah I experienced the same. If this problem could be solved, that would be great. For now it's just impossible to attach a modifier to reverb time. Even a scene 1/2 modifier, which jumps directly from value A to B without any in-between progression, makes CPU crazy. Changing pre delay is fine but not reverb time.
 
I've encountered this in a few presets so I tried a blank slate to see what was really going on.

A preset with nothing in it, just a reverb block, uses about 24-37% depending on reverb settings.

Attaching any modifier (Scene Controller, External Controller, etc) to the Reverb Time causes the CPU to jump anywhere to 75%. High reverb times (even 100 seconds) do NOT cause the CPU to spike like this when set without a modifier. This renders Reverb Time useless with modifiers, for actual preset usage.

Hopefully this is just a bug that can be fixed, as I'm in need of building some presets where the reverb time can smoothly fade between long trails or short trails.
This will be corrected in the next release.
 
Back
Top Bottom