Letting a delay fade out whilst stopping process more input

General JUCE discussion
1

Hi, I’m using a JUCE Delay for some delay processing.

I currently have a switch to turn it on and off - this basically determines whether process() is called on the delay processor. This is all good, but when I turn the delay off, as it’s not processing any more, the delay that is going through gets cut off abruptly.

How do I stop the delay processing more input whilst allowing the existing delays to finish their processing.

Thx

2

What if you split the buffer into a dryBuffer and a delaySendBuffer?

And instead of turning process() on or off, have the “on” button to cause a the dryBuffer to quickly fade out while the delaySendBuffer quickly fades in - and vice versa.

delaySendBuffer is then passed into the delay which is always processing.

And then add the processed delaySendBuffer and the dryBuffer back together

1 Like
3

thx

bit beyond me to be honest - the process() call only takes a single buffer, so not sure how the delayBuffer, dryBuffer and delaySendBuffer would factor into things…

Plus, also, say the delay has a high feedback on it that would take a minute to fade out, not sure how that would be handled by the above quick fade you’re talking about?

thx

4

I just edited my post. So there’s only 2 buffers. A dryBuffer and a delaySendBuffer. The dry buffer is just your original buffer.

The key here is that the fade occurs before the delay process(), not after.

Just like if you turn up the send knob on a mixing console, and then turn it down, the delay will continue to process the tail of everything up until when you turned down the knob.

So it’s just switching between
100% dry gain + 0% send
And
0% dry gain + 100% send

I can make a code example if you like

1 Like
5

that would be great, thx

this is the delay I’m using:

https://docs.juce.com/master/tutorial_dsp_delay_line.html

1 Like
6

Ahh using that tutorial project will be quite handy - sure I’ll make an example!

1 Like
8

Check the processBlock in the PluginProcessor.cpp file here!

2 Likes
9

thanks - I will check this out today!

1 Like
10

should this have a brace around it?

if (delayBuffer.getNumSamples() != numSamples)
    delayBuffer.setSize(totalNumInputChannels, numSamples);
    delayBuffer.clear();

thx

1 Like
11

Yes good call. It works without the brace but it’s more correct to have it in a brace so it’s not clearing every time. Just fixed the code.

1 Like
14

right, after a few twists and turns this is working well, and i now understand the principle, so thanks for that!

when enabling/disabling the fx, i’m still getting some audio glitches, which I hoped the fades would take care of.

any suggestions?

thx

15

I never enabled Microphone access in the Projucer but you can enable it in the Xcode exporter section. Or just build the plugin version and see if it works as expected

Glad the project is helping you!!

Is the the delayToggleSmoother being given a sample rate and smoothing time in the prepareToPlay? I tried disabling that and I got the audio pops you’re describing.

Also just a note: this code could be improved by adding some function that turns off the delay processing once it has finished its tail. It doesn’t take up much CPU right now but if it had things like oversampling, more filters, distortion, etc on it, it could be a worthwhile optimization.

1 Like
16

when the button is pressed that is supposed to stop the input, just feed zeros into the delay. that will make it slowly fadeout with what’s left in the ringbuffer

1 Like