Bypassing a hosted plugin

[anthony-nicholls]

If we are going to consider implementing this via a parameter that is marked as a bypass parameter then I have suggested this before (twice)…

Parameter Category - Bypass

I just noticed the added ability to specify a category of a parameter. Would it not make sense to have a bypass category? This way the wrappers would first search to see if there is a bypass parameter defined based on this category and otherwise add the bypass parameter if necessary (such as for VST3) as they currently do. The advantage being that the plugin is then able to access the bypass parameter so for example a bypass parameter could be added to the GUI that is kept perfectly in sync with…

We are removing AudioProcessor-based parameter management

Sorry this should probably be a seperate thread but I would second the work of separating the meter and parameters, it’s annoying that getting the number of parameters is really the number of parameters plus the number of meters, in my mind they are separate concepts. Sorry to jump on the band-wagon but while we’re making such suggestions, I would also suggest some ability to mark a parameter as a bypass parameter. The Wrappers could check if any of the parameters are the bypass parameter and p…

However keep in mind that not all wrappers implement the bypassing mechanism as a parameter (VST2 and AU for example).

I think reporting a bypass parameter to the host is a good solution to deal with it from the plugin side. However on the host side there will be no way to know if the parameter is a bypass parameter or not for VST2 and AU (I think that includes AUv3) - so in other words it would only work for VST3 forcing any host that wants to host VST2 and AU to fall back to calling processBlockBypassed().

You could add a special parameter for VST2 and AU that deals with this on the hosting side but then you would be reporting an extra parameter that isn’t really there, imagine showing a list of available parameters to a user, which bypass parameter should they automate?

So I think that from the host side there needs to be a set/isBypassed and a bypassChanged callback, however to reduce confusion IMO it should be in the AudioPluginInstance class.

Keeping processBlockBypassed in the host could continue to work as it always did (no need to bypass or un-bypass) this way existing hosts work as they always did, no change in functionality. Future hosts should probably rely on setBypassed() however if they wanted to override that behaviour they could. For example Cubase has both a bypass and a deactivate, so a host could release a plugins resources and use the processBlockBypassed to pass audio through without it actually having to call into the plugin, but for the normal bypass procedure it would call setBypassed() and continue calling processBlock.

Hopefully that makes some sense.

EDIT: Also thanks for taking the time to look into this with so much consideration.