Current state of bypass management

Hi guys,

I’m trying to deal with the situation where hosts are not calling processBlockBypassed when a plugin gets bypassed via the host bypass buttons. I’ve read several threads, some of them dated almost 10 years ago, and the situation looks basically unsolved.

I know about getBypassParameter method, but I don’t think that’s a reliable solution. Most hosts looks like to just not calling processBlock any longer, when their bypass is on, so there’s no way (afaik) to reliably detect the bypass state and clear buffers (or do anything we need to do when the plugin is bypassed). EDIT: looks like getBypassParameter is not getting called at all. I tried overriding the method and it’s never called.

Right now, I’m trying with a bare boolean to detect if processBlock is working

isProcessing = true;     //first processBlock row
//--- my processing code ---
//isProcessing = false;  //last processBlock row

Then I can check the state of this bool in getStateInformation, since it’s seems to be called when the bypass button on the host is clicked. That works but it’s obviously useless if you need to do buffer operations, so I’m back to square one.

I also tried to check if the processor gets suspended, but looks like it is not… so, basically, there are hosts (like Live, Reaper, maybe Logic Pro) which are simply not calling processBlock or entirely skipping the plugin in the chain.

Has anyone found a viable workaround to this?



Some hosts allow disabling the plugin entirely in addition to bypassing it. It’s also not uncommon that the plugin is suspended (e.g. no processing is ever called) to save CPU, Logic is very aggressive with that. There is also no rule that forces a host to support the soft bypass of your plugin in addition to its own bypass mechanics.

Long story short: Neither can you rely on processBlockBypassed being used, nor can you reliably detect if the plugin is suspended.
The best workaround for “plugin is inactive” detection I have found so far is storing a timestamp in my process callback and having the UI test how long ago that was. If it’s more than X (few hundred ms), I use this to fade out some audio engine visual feedback. I’m also making sure that everything works from a usability perspective without any audio processing ever happening. This is important for cases like “offline processing” in Cubase, for example.

I’d also recommend not making any assumptions on when exactly getStateInformation will be called. Host behavior is wildly different when it comes to that. I’ve even seen situations where hosts call setStateInformation during a process callback (which should never ever happen - but it does). Best play it as safe as possible, and assume that hosts will interpret the plugin interfaces creatively to the point of ignoring specifications.

1 Like

that was my assumption too after struggling with this :smiley: Thanks for your feedback, @jcomusic. Your timestamp suggestion could be a fine workaround.


Thanks @jcomusic. I used a similar workaround, but stored in processBlock.

Basically I store, at the end of processBlock, the value of Time::getMillisecondsCounter()
At the very beginning of processBlock, I get another call to getMillisecondsCounter and compare it with the previously store. If the difference between the two is over a predefined threshold, I call the methods I need to clear my buffers. Works flawlessly.