Add latency compensation for block bypass

[pierreguillot]

It seems that it should done manually in the processBlockBypass() method of the processor.

[pierreguillot]

Perhaps the plugin should send a notification to the patch and let it manage with a [block~] object. This way, the plugin can still receive the other events...

[alfonso73]

Hi Pierre, what this feature is intended for?

[pierreguillot]

Plugins have a bypass option or a bypass parameter (VST3). For the moment, when a plugin is bypassed, the DSP method of Pd is avoid and the incoming signals are unchanged. But if the patch implies latency, bypassing the plugin will creates artifacts such as pre-echoes or time-shifting. Moreover, one could want to cross-fade the signals to avoid glitches and crackles for examples.

The solution I'm working on is to add an option to deactivate the automatic bypass and let the plugin creator the possibility to manage it in the patch when receiving the notification (bypass 1 or 0). This way, the latency could be preserved and to avoid crackles, he could apply a ramp on the signal and use the object [block~].

[pierreguillot]

Here are several way to use this feature: Important: Use the option autobypass false.

• To preserve latency and to avoid time-shifting (when using delays, FFT, etc.):

• To apply a cross fade between the wet and the dry signals:

Note: You combine the two mechanisms.

• To avoid unnecessary computation:
  Important: This mechanism, must be used in a subpatch or abstraction where the transformation of the original signal is performed. The two previous mechanisms to switch between the wet and dry signals must still be active.

[pierreguillot]

Close - see bypass