How to detect if plugin is active?

Audio Plugins
1

Basically I want the editor to stop responding to mouse events while the plugin is turned off.

So I need to detect when the plugin is turned On or Off. Is this possible?

Thank you
Andres

2

typically the host sends buffers with numSamples == 0 when it wants to tell the plugin that there’s nothing to process rn. you could use these moments to set some atomic bool to false, which could then be read by the editor

3

Not sure what you mean by turned On or Off. Do you mean when Bypassed vs. not Bypassed? When the Editor is shown versus not shown? When Activated in a host that has an Activate (On/Off) button instead of (or in addition to) their Bypass button?

VST3 hosts can call setActive(bool) to tell a plugin that it is “active” or not. That gets fed to the more generic functions prepareToPlay() (after which the transport is allowed to start) and releaseResources(), after which the transport is not expected to run.

Not sure if this helps, but if you need more info, then we could use more info from you as to exactly what you mean by On and Off (and whether you’re targeting a specific plugin type, such as VST3).

4

Thank you @Mrugalla and @HowardAntares

Sorry if it was not clear. By On/Off I try to indicate whether the plugin is actively processing audio or not.

By pressing this button on Logic the plugin alternates states On/Off


Screenshot 2023-06-12 at 1.43.00 PM

What I did was check if the “processBlock” in being called or not.

5

That button only affects Logic’s behavior, I think. Pro Tools also has an Activate/De-Activate button that does a similar thing. The plugin is not told of this change, as far as I know. It just stops the plugin from receiving audio during playback. A kind of “hard bypass”, I guess.

Some hosts have this, some do not. VST3 plugins have a setActive(bool) function as I mentioned earlier, but not AU or AAX. There is a master bypass, but that is different, and (if hooked up in the plugin) will allow you to detect that condition.

But detecting if the transport has been called recently does not tell you if it will be called at any moment. Logic stops calling processBlock() when the transport is stopped if you’re using an audio effect or midi-controlled audio effect, and also stops calling the plugin when the transport is running but there is no audio in that part of the track. (Unless you use a certain trick to allow it, and are white-listed by them for that explicit purpose.)

Solving for a Logic-specific may not be the way to get the behavior you want in all AU hosts, though, given that this control is Logic only.

I don’t know why you would not want to allow the plugin to respond to the mouse when de-activated like this, though. I would assume that users will quite likely want to still interact with the plugin when de-activated, in order to set up the plugin with the settings they want when they do re-activate the plugin. It lets you keep the transport running while making changes that do not affect the output until you re-activate it, so it seems useful to keep your editor alive regardless of the state of that button in Logic.

6

The tests are done only on Logic, Reaper, ProTools and Ableton and fortunately, so far it has behaved as expected. The mouse response is only for a couple drag-n-drop dots that need to be unresponsive in this state.

7

But won’t it also disable that ability if you simply stop the transport in Logic, or if the transport is in an area with no audio on that portion of the track? Or are you not using an audio effect or midi-controlled audio effect? It does receive callbacks when using a generator or instrument (unless that button is turned Off).

8

If the DAW does not provide any notification of this state, you can use a ‘watchdog’.
The idea is that everytime the DAW call the process function, you update a counter.
On the GUI side, you ‘watch’ that counter, if it stops incrementing for too long, you can assume that the DAW is no longer calling the process function.

2 Likes
9

This is precisely what I do. Thank you.

10

Hello this is Gulshan Negi
Well, yes you can detect whether a JUCE plugin is turned on or off by utilizing either the plugin parameters or the host automation system.
Thanks

11

This topic interests me but I don’t see the obvious solution in any posted answer (not obvious to me anyway).

I have created a VST3 plugin modeled after the JUCE Arpeggiator effect example. I want to be able to know when the effect is bypassed or not. I’m using Cakewalk by Bandlab as a test host.

setActive(bool) is a member of the ApplicationCommandInfo struct. I don’t see how that struct can be woven into my plugin source code so I can access setActive(). I’m not convinced the function is even correct for my task.

Would somebody please provide some example code snippets or point to some example code that does what I need?

Thanks - JJS

12

I’m going to attempt to start to answer this question and hopefully I’ll be steered correctly:

This Steinberg forum thread link says “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” in the third entry by Arne_Scheffler. That advice correlates to a comment related to the kIsBypass parameter flag in the ParameterInfo definition in ivsteditcontroller.h from the JUCE modules directory. It says “special bypass parameter (only one allowed): plug-in can handle bypass (highly recommended to export a bypass parameter for effect plug-in)”

That advice tells me I need to create a plugin parameter, and set the parameter flag kIsBypass. It sounds easy but I am not able to see how to set the flag after calling addParameter(). Can anyone help with that?

13

You can override the getBypassParameter() function in your audio processor.
See the documentation in juce_AudioProcessor.h

1 Like
14

Thanks, rcohen. I think you’re saying:

  1. The plugin adds the bypass parameter to the plugin at initialization.
  2. The plugin implements the getBypassParameter() which will return the pointer to the bypass parameter.
  3. The plugin tests the bypass parameter in processBlock() to determine if it’s bypassed.

I assume the host will call getBypassParameter() so the host can set or clear the bypass parameter as the host desires.

Is that correct?

Is the kIsBypass flag implicitly set in that case?

15

Hello @johnspeth .

Yes, I think you have it correct.

Here’s a code snippet from juce_VST3_Wrapper.cpp:

            if (isBypassParameter)
                info.flags |= Vst::ParameterInfo::kIsBypass;
1 Like
16

I just tested the code I described in my 3 step plan. Unfortunately Cakewalk by Bandlab does not call the plugins’ getBypassParameter() function. Actuating the Bypass checkbox on the plugin GUI does correctly toggle the Bypass state. Based on those observations, either:

  • Cakewalk is not bypassing the plugin as expected so it’s a Cakewalk failure which I need to live with.
  • The kIsBypass flag is not getting set by the plugin so the host knows it’s the special bypass parameter.

My Juce installation does not have any juce_VST3_Wrapper.cpp file. In fact, the file is nowhere on my computer, which includes my source directories. Why is that? It seems there is some sort of tool difference. This difference makes me think I’m creating the bypass parameter incorrectly.