VST3 bypass can leave a plug-in's processing function running, because Steinberg defines bypass as a parameter the processor itself handles. The audio may pass through untouched while the plug-in is still very much part of the signal path.
This is where people get tripped up. You click a bypass button, the effect disappears, and it feels reasonable to assume the DAW has stopped doing anything with that plug-in. Sometimes it has. Sometimes the host is still calling it, tracking its latency, preserving its state, or keeping it ready for a clean return.
The difference makes more sense once you separate sound from execution. Audio plug-ins inside a DAW can be audible, bypassed, suspended, deactivated, frozen, or removed, and those states are not interchangeable.
The plug-in then has work to do. It may need to copy input audio to its output, preserve reported latency, ramp between processed and dry signals, and avoid clicks when bypass changes during playback. A processor with lookahead cannot simply pretend its delay vanished without risking a timing jump.
So bypass is often better understood as "do not apply the audible effect" rather than "stop executing this software." The distinction sounds pedantic until a big mastering chain is bypassed and the CPU meter barely moves.
Host behavior matters just as much. Logic Pro says bypassed plug-ins do not drain system resources, while Ableton says turning a device off is like temporarily deleting it and stops CPU use for Live devices. Other hosts distinguish bypass from a separate off or deactivate state. One word on the screen can therefore hide different plumbing underneath.
Cubase exposes this through its option to suspend VST3 processing when no audio signal is received. A silent section can therefore use far less processing even though the plug-in remains loaded, configured, and ready for the next note. Reverbs and delays complicate the picture because a silent input does not mean a silent output while a tail is still decaying.
The broader architecture behind this is not exotic. The iPlug2 audio plug-in architecture paper describes modern plug-in designs that separate real-time processing from controller and interface work. Closing a graphical window, bypassing DSP, suspending an audio callback, and unloading an instance can therefore affect different chunks of the software.
Memory is another reason CPU readings do not tell the whole story. A bypassed or inactive plug-in may stop heavy audio processing yet keep samples, impulse responses, graphical resources, preset data, or other allocations in memory. Removing or unloading it can release more than simply bypassing it.
If the goal is freeing resources in a huge template, look for the host's stronger option instead. Words such as deactivate, disable, off, freeze, or unload usually point closer to actually stopping processing, although the exact behavior still depends on the DAW and format.
Freeze goes further by rendering the current result to audio and taking active instruments or effects out of the real-time workload. It trades flexibility for breathing room. Removing the plug-in goes further again, but now you have also removed its place in the chain unless the host offers a reversible inactive state.
Latency deserves one last check. Some hosts deliberately keep compensation in place while an effect is merely bypassed so playback does not jump when you switch it back on. A track can therefore sound dry yet still behave as if the delayed processor exists. If you are chasing CPU or recording latency, "I bypassed everything" is not proof that everything has stopped.
This is where people get tripped up. You click a bypass button, the effect disappears, and it feels reasonable to assume the DAW has stopped doing anything with that plug-in. Sometimes it has. Sometimes the host is still calling it, tracking its latency, preserving its state, or keeping it ready for a clean return.
The difference makes more sense once you separate sound from execution. Audio plug-ins inside a DAW can be audible, bypassed, suspended, deactivated, frozen, or removed, and those states are not interchangeable.
Bypass can keep the processor alive
VST3 makes this unusually clear. A plug-in can expose a bypass parameter, and when you hit bypass in the host, the change is passed into the processor like another parameter update. Steinberg's own developer documentation says the process method can continue being called while bypass is active.The plug-in then has work to do. It may need to copy input audio to its output, preserve reported latency, ramp between processed and dry signals, and avoid clicks when bypass changes during playback. A processor with lookahead cannot simply pretend its delay vanished without risking a timing jump.
So bypass is often better understood as "do not apply the audible effect" rather than "stop executing this software." The distinction sounds pedantic until a big mastering chain is bypassed and the CPU meter barely moves.
Host behavior matters just as much. Logic Pro says bypassed plug-ins do not drain system resources, while Ableton says turning a device off is like temporarily deleting it and stops CPU use for Live devices. Other hosts distinguish bypass from a separate off or deactivate state. One word on the screen can therefore hide different plumbing underneath.
Silence and suspension are separate CPU tricks
A processor does not always need to be fully bypassed before the host can save work. VST3 has silence flags that let hosts and plug-ins identify buffers containing no meaningful audio, so unnecessary calculations can be skipped during quiet passages.Cubase exposes this through its option to suspend VST3 processing when no audio signal is received. A silent section can therefore use far less processing even though the plug-in remains loaded, configured, and ready for the next note. Reverbs and delays complicate the picture because a silent input does not mean a silent output while a tail is still decaying.
The broader architecture behind this is not exotic. The iPlug2 audio plug-in architecture paper describes modern plug-in designs that separate real-time processing from controller and interface work. Closing a graphical window, bypassing DSP, suspending an audio callback, and unloading an instance can therefore affect different chunks of the software.
Memory is another reason CPU readings do not tell the whole story. A bypassed or inactive plug-in may stop heavy audio processing yet keep samples, impulse responses, graphical resources, preset data, or other allocations in memory. Removing or unloading it can release more than simply bypassing it.
Deactivation is the cleaner move when CPU is tight
If the goal is a quick A/B comparison, bypass is usually the right control. It keeps the plug-in ready, preserves the chain, and can avoid timing interruptions when you switch it back in. Automation also makes much more sense when the processor remains prepared to rejoin playback cleanly.If the goal is freeing resources in a huge template, look for the host's stronger option instead. Words such as deactivate, disable, off, freeze, or unload usually point closer to actually stopping processing, although the exact behavior still depends on the DAW and format.
Freeze goes further by rendering the current result to audio and taking active instruments or effects out of the real-time workload. It trades flexibility for breathing room. Removing the plug-in goes further again, but now you have also removed its place in the chain unless the host offers a reversible inactive state.
Latency deserves one last check. Some hosts deliberately keep compensation in place while an effect is merely bypassed so playback does not jump when you switch it back on. A track can therefore sound dry yet still behave as if the delayed processor exists. If you are chasing CPU or recording latency, "I bypassed everything" is not proof that everything has stopped.
