Doing some Dry/Wet mix without any latency is pretty common.
At the moment the DryWetMixer always push the samples to the delayline and call its process even when the latency is 0.
That’s quite inefficient, and as DryWetMixer is constructed with a maximumWetLatencyInSamples parameter that will stay constant through the life of the DryWetMixer, I suggest to bypass all the delayline calls when maximumWetLatencyInSamples is 0.
Not sure if branching is optimizing things as pushing and pulling from an integer delay (which uses no interpolation) is really fast. Also I usually favor constant load over a lot of branching. Run a performance profiler if you have doubts.
The delayline uses a thiran interpolation which already has a branching in its interpolation code.
So if you don’t have any delay that should always be more efficient to have the branching at a much higher level and bypass all the delayline code ?
Interesting, I rolled my own DryWetDelay and assumed JUCE’s isn’t using interpolation since it’s an integer delay - what’s the reason for using interpolation there?
it’s not an integer delay, setWetLatency() takes a floating type.
I hadn’t seen that before - you’re right, and the method’s signature is setWetLatency (SampleType wetLatencyInSamples)
However, that seems conceptually off to me, for the SampleType to also determine the type used for the latency. SampleType in general correlates to bit depth of the samples - however, latency, being a measure of time, correlates to the sampling rate. Why the two types should be linked, I am not clear.
If the latency needs to be done using a floating type, I would have expected it to use a double, since that’s what all the JUCE DSP classes use for their sample rates.
That said, I’m also not clear how often anyone needs a non-integral latency time, and therefore how necessary it was to design DryWetMixer’s latency compensation to use an interpolating delay.
Perhaps it’s there to cope with juce::dsp::Oversampling’s non-integer latency?
Sounds like it should have three separate implementations to me, maybe with different names or if you must, switchable at compile time with some template shit.
I’ve updated the DryWetMixer so that it just copies samples when the maximum latency is set to 0:
Thanks to @reuk for the optimization!
And yes the non integer delay feature is because there are a lot of processes that can have a non integer latency, oversampling being one example…
