HurdyGuigui
Inspired
Up,
Still no workaround to clear this buffer?
Still no workaround to clear this buffer?
Improved Stack/Hold behavior in Delay block:
- In Hold mode repeats are now infinite (or nearly, may degrade over many minutes/hours)*.
- Added Stack Feedback and Hold Feedback parameters. This allows adjusting the decay time independently for the stack and hold modes.
- Improved transition between Stack/Hold states.
Ohh, it sounds interesting ! I didn't update for a while because I have lot of shows those days so I think I am still around firmware 20 or 21...If you mean in Stack/Hold modes since 24.00, I believe you can turn down those feedback parameters as needed. Otherwise, turn down delay feedback. Of course these would not be triggered automatically based on whatever scenario (e.g. changing presets or channels) which I think is part of the wish.
If you clarify your particular use case(s) again, that might help figure out a solution.
From 24.00 release notes:
Up,
Still no workaround to clear this buffer?
Consider the case of the Echoplex, where the play head is stationary and the record head moves instead.VST/AU delay effects have the ability to clear the buffer, but that’s because there is a specific protocol for that purpose, which is used, for example, when resetting the transport. I’ve wtitten a lot of delay effects in my time and I would consider it to be rather odd if changing the delay time caused the buffer to clear.
I guess it is "clearing the buffer" (or part of it) in the domain of the Echoplex. What the OP is talking about, I'm not sure. It's just a response to "I would consider it to be rather odd if changing the delay time caused the buffer to clear" and an example of where changing the delay time would dump part of what was in memory.Ok, but that's not "clearing the buffer", right? I think the use case the OP is talking about is: leave the delay time unchanged but clear the buffer so the echoes stop immediately.
Maybe a clear-buffer-on-selection option. Turn it on, and the buffer is cleared when that preset s selected.
If so, that would clobber all tails, even for the same type (and settings) on a different channel. This might be okay if the setting you propose would be optional.Running into this issue where when I change delay channels and there’s different types in each channel, if I’m playing a passage and switch to a different channel, then come back to the original channel, I get this burst of sound that is the content left in the original channel’s delay “memory”.
So my wish is to clear the delay “memory” when changing channels.
That's a good point. But I don't notice the issue when switching between channels that have the same model selected so I guess that's my workaround for now.If so, that would clobber all tails, even for the same type (and settings) on a different channel. This might be okay if the setting you propose would be optional.
If "clear delay buffer" were configurable across scenarios (e.g. by modifier trigger / midi, on channel change, on preset change, on scene change, on any change), this seems ideal, but probably challenging to implement.
Running into this issue where when I change delay channels and there’s different types in each channel, if I’m playing a passage and switch to a different channel, then come back to the original channel, I get this burst of sound that is the content left in the original channel’s delay “memory”.
So my wish is to clear the delay “memory” when changing channels.
Good point.Some types share a buffer, others don’t. When switching to a type that doesn’t share a buffer, the first buffer should be cleared. It’s hard to imagine a use case that would justify the current behavior of not clearing the buffer in that particular situation. In the meantime you’ll have to use one of the workarounds I mentioned above.
Good point.
So it would have to clear it based on knowing the prior state/type it was coming from. Only if the type/buffer changes would it be cleared upon switching to it. There might be a CPU cost/latency to clear/zero it on demand like that (assuming it is static memory of fixed length).
There obviously isn't a simple solution