When the latency of a plugin is not null, we must override
AudioProcessor::processBlockBypassed() and compensate it there to avoid timing issues.
So I suggest to add the following in the default
AudioProcessor::processBlockBypassed() implementation :
// your processors has some latency but you haven't
// overridden AudioProcessor::processBlockBypassed().
// you must override it to add latency compensation to avoid situations
// where bypassing will shift the signal forward in time
jassert (getLatencyInSamples() == 0);
Since the number of latency samples is known, there could be even a default delay line in processBlockBypassed…
But somehow I remember issues with “clever” hosts not calling processBlockBypassed at all?
If that’s the case, all is lost anyway…
sure… when we’ll have a delay line in juce!
meanwhile an assertion would do the job. it’s just to remind us that we got to take care of that and avoid situations like that one for instance : Cubase latency issues
thanks for the commit Tom !
I’m gonna bump this for @t0m since this really needs to be handled in the AudioProcessor class itself for an AudioProcessorGraph. I can hack the AudioProcessorGraph to add my own mod… but that still feels like it should be handled by AudioProcessor::processBlockBypassed() which is called by all the plugin format types if it’s not handled by the plugin being hosted.
I’m sure y’all can add a simple delay line and use that in AudioProcessor::processBlockBypassed().
Please see: [FR] DSP Delay Line (for AudioProcessor::processBypassed())