"Host Bypass" - VST2 vs. VST3 explanation?

Can someone point me to an overview/explanation of how “Host Bypass” works in VST3 (vs. VST2)? I can’t seem to get my arms around what should be a simple, basic function.

Thank you.

BTW - a lot of name-brand plugins I own from other developers do not bypass correctly from the host - so it seems this is a common problem area in VST3

In VST3 you can register a dedicated bypass parameter by setting the ParameterInfo::kIsBypass flag and a proper VST3 host implementation should take care of synchronizing that parameter with its internal bypass state. As a plugin programmer you can react to bypass changes, e.g. by intercepting changes to the bypass parameter in your IEditController::setParamNormalized() implementation.

In VST2 the host first asks your plugin whether it supports VST 2.4’s AudioEffectX::setBypass() API by calling canDo(“bypass”). If it does, a proper VST2 host implementation will set the bypass state via AudioEffectX::setBypass(), which is where you can react to changes. I think this is what some hosts (e.g. REAPER) don’t get it right/don’t implement at all. REAPER for example just stops calling your plugin’s process function altogether and bypasses the respective audio stream internally when your insert is in bypass without ever calling setBypass(). All that is handled by Steinberg’s Vst2Wrapper given that you’re exposing a bypass parameter in your VST3 implementation btw…

If a specific host implementation doesn’t conform to these protocols, there is not much more you can do except for supporting the outlined VST2 / VST3 APIs and hoping for the best :wink:

Best,
Ray

Hi,
from the FAQ in the documentation:

Q: How does Audio Processing Bypass work?

In order to implement audio process bypassing, the Plug-in can export a parameter which is additionally and exclusively flagged as having the attribute kIsBypass. When the user activates the Plug-in bypass in the host, like all parameter changes, this is sent as part of the parameter data passed to the Vst::Steinberg::IAudioProcessor::process method.

The implementation of the bypass feature is entirely the responsibility of the Plug-in:

The IAudioProcessor::process method will continue to be called. The Plug-in must take care of artifact-free switching (ramping, parallel processing or algorithm changes) and must also provide a delayed action if your Plug-in has a latency. Note: The Plug-in needs to save in its state the bypass parameter like any other parameters.

What is not clear ?

Cheers,
Arne

I think some confusion here comes from the fact that in Cubase depending on where you activate bypass (mixer slot vs. plug-in window) it’s either using host bypass or relying on plug-in bypass, disabling the bypass feature if the plug-in does not support plug-in side bypass. I wish it would just fall back to host-side bypass for that button if plug-ins do not support bypass - as it is now, it basically forces all plug-ins to implement bypass even if it does not make sense for the given plug-in since it doesn’t do anything special while bypassed and host-side bypass would be preferable and yield better performance.

Best,
Stefan

It seems from what you posted here that this is really nothing more than another control parameter passed to the plugin. So why do so many hosts and plugins get it WRONG? It seems simple, unless I’m missing something.

I already have my own “soft bypass” control in my plugins as an automatable parameter. So it seems I just need to connect it up to the kIsBypass parameter?

>>In order to implement audio process bypassing, the Plug-in can export a parameter
What happens if your plugin does NOT export this parameter?

Great info, thank you.

Since I didn’t understand the formal way to do this - and I know it’s different for VST2/VST3 - I created my own bypass parameter in my plugin. It works the same regardless of VST version (VST2 or VST3) because it’s simply another “control” parameter. I thought that was a good approach but then some customers complained that “host bypass” didn’t work right in Cubase - so now I’m trying to figure out how to do it per VST spec.

BTW - What’s complicating my efforts is that I’m building my plugins for VST2, VST3 and AU formats on both Mac and PC using a cross platform tool called iPlug. Unfortunately that tool does not seem to have Host Bypass working properly…

Maybe the developers don’t read the documentation.

Correct. Easy, not ?

Then the host may implement bypass of its own, or if not then it just don’t allow to bypass that plug-in.

This seems to be the biggest problem right here. What works in Cubase does not work in other DAWs and vice versa. It’s actually a mess, IMO.

I am just going to keep using my own built-in “soft bypass” parameter and advise customers to use it instead of Host Bypass.

Just mark your bypass parameter as kIsBypass and you’ve done the correct thing. If there are hosts that don’t work with this correctly, report it here and we’ll try to talk with the developers to correct this.

Cheers,
Arne

It seems kIsBypass is only for VST3? How would I “connect it up” in VST2?

Don’t know about other hosts but for one kIsBypass is not called by Cakewalk by Bandlab when the Host Bypass is engaged. I actually don’t know WHAT it does but Cakewalk itself must be taking care of the bypass internally. It does Bypass the plugin but it is not a seamless transition if the plugin has latency.

Hi
i will inform the Cakewalk developers about this non-conform use of VST3 bypass:

  • when the plugin provides a bypass parameter (which is flagged with kIsBypass), the host should uses it when the user will bypass it.
  • when the plugin does not provide a bypass parameter, the host could choose to implement its own bypass processing or not.

kIsBypass is not a call. Its a flag that the plugin uses to indicate that a parameter is a bypass parameter. We definitely check for the presence of that flag and use that parameter as the host bypass parameter. Its implemented in fact exactly as the Steinberg SDK code samples did it. In Cakewalk host bypass is controlled by the button on the plugin window toolbar (top left). That button will be grayed out if the plugin doesn’t expose a host bypass parameter.

For VST2 we don’t support “soft bypass” out of the box because the AudioEffectX::setBypass() used to have problems with some VST2 plugins and wasn’t universally implemented properly. There is a way to enable support for it in Cakewalk via a config flag however. VST2 bypass is limited because there is no API to query the bypass state only to set it. And yes kBypass doesn’t apply to VST2 since bypass is not a parameter there.

  • Noel Borthwick

Thank you for the info. RE VST3, the Host Bypass parameter does not appear to have any effect in Cakewalk but it does work in Cubase. I call “GetIsBypassed()” from my iPlug framework and Cakewalk returns nothing - Cubase returns bypass status (bool IsBypassed). So what do you think the problem could be?

Also, since I have your attention, Cakewalk does not seem to load the last factory preset in VST3 plugins. The VST2 version of the plugins loads all the presets but selecting the last preset in the VST3 versions does nothing, i.e., instead of “kNumPrograms” it’s loading kNumPrograms - 1.

Is the bypass button grayed out? If so Cakewalk thinks that your plugin doesn’t support bypass because I did not find a parameter flagged as a bypass param. If you send me a link to your plugin I can tell you why.
Regarding the factory preset issue again send me a link to your plugin and I can investigate it. You can PM me on our forums at https://discuss.cakewalk.com or send me a private message here if you like.

just to clarify the “Bypass” parameter in VST3 for hosts:
Is it recommended to expose this parameter?
Also, when the bypass is true, what’s exactly supposed to be handled in a host program? Like the output buffers must be cleared out and basically nothing be activated when it comes to parameter changes and midi events?

Yes it is recommended to have this bypass parameter for FX plugins (not for Instrument).
The host should always continue to process the plugin, with parameter changes and note events,
What is done by the plugin in a bypass state is its decision.
Expected is that the output buffers contains the input buffers including the delay compensation.