Boolean VST Parameters With AudioProcessorValueTreeState

Audio Plugins
1

We have some boolean parameters in our plugin created using:

parameters.createAndAddParameter(
        paramID,
        paramName,
        "",
        juce::NormalisableRange<float>(0.0f, 1.0f, 1.0f),
        0.0f,
        [](float value)
        {
            return (value > 0.5f) ? "On" : "Off"; 
        },
        [](const String &text)
        {
            if (text == "On")
                return 1.0f;
            else if (text == "Off")
                return 0.0f;

            return 0.0f;
        },
        false,
        true,
        true
    );

There are 2 interrelated issues that we are struggling with:

  1. Some hosts (such as Mixbus & Reaper) are not showing the VST parameters as a boolean ”switch” in the generic host-provided GUI or the automation lane. Presumably the hosts are expecting the VST opcode that provides parameter flags including “IsSwitch”. We couldn’t find that flag implemented in the JUCE wrapper so we started to add it.

  2. While attempting the change above it became obvious that parameters created in an AudioProcessorValueTreeState do not override AudioProcessorParameter::isBoolean(), so they always return false. A quick fix would be to check for isDiscrete() && getNumSteps() == 2, but our plugin has some discrete 2-step values that are not strictly switches (e.g. a menu with only 2 choices).

How can we further distinguish the type of parameter with createAndAddParameter? Will the interface eventually allow us to define whether or not a parameter is a boolean, or is using subclasses (such as AudioProcessorParameterBool) the only way to achieve this?

1 Like
2

Does REAPER actually call effGetParameterProperties (56)? I just printed out all the opcodes received by a plug-in and I couldn’t spot it…

3

We just tested out Reaper again today and they may not be handling switches all together for VST. With their ReaComp plugin the generic editor & automation lane allow their boolean params (“Classic Attack” and “Auto Release”) to have values between 0 and 1.

Bitwig Studio is actually treating our own parameter in that same way, giving it a slider and not adhering to its 0-1 discrete values.

We’d like to support boolean parameters on as many hosts as possible. Are there other ways with the AudioProcessorValueTreeState to give the host that information? Will something like bool isBoolean be added as an argument to createAndAddParameter or should we convert to using subclasses to achieve overriding isBoolean()?

4

I’ll add an isBoolean parameter to the APVTS parameter constructor, but I don’t think it will help - if REAPER isn’t requesting that information via the VST API then there’s nothing we can do.

An alternative may be to provide a .vstxml file with your plug-in, http://www.dith.it/listing/vst_stuff/vstsdk2.4/doc/html/vstparamstruct.html , but I don’t know if REAPER supports that either.

Do you know of any other VST plug-ins which are able to display switches in REAPER’s parameter view?

1 Like
5

Thanks @t0m, that would definitely help out on our end being able to set isBoolean via AudioProcessorValueTreeState even if Reaper still isn’t implementing switches correctly

I think you’re correct in that Reaper doesn’t support vstxml: https://forum.cockos.com/archive/index.php/t-181225.html

I’ve tried with a few other plugins between 3rd party plugins and built-in plugins and still had no luck, both Reaper & Bitwig will display everything as a non-discrete slider in VST (and as discrete sliders in VST3)

6

It’s hard to predict when DAWs will show a checkbox or a switch instead of a slider. For example, Logic will display a switch for discrete parameters with two values and a combobox for parameters with more than two values. If you also make your parameter boolean then Logic will display a checkbox if the corresponding text values are “On” and “Off”, but not if they are “0” and “1”.

7

Indeed, this is one of the more frustrating aspects of plugin interfaces that we’ve encountered for Ardour/Mixbus.

For VST, we check for the boolean flag in effGetParameterProperties.

For AU, we check the provided AU flag but we also check for a 2-state integer switch. Perhaps we should instead do the same “On”/“Off” check as Logic, as a backup.

If JUCE would implement this properly then it might reduce some of the headaches. The fact that the IsBool flag was left out of TreeValueState is a pretty big oversight. But easily fixed I hope.

-Ben at Harrison

8

@t0m There’s a similar problem with Discrete parameters.

Params created with TreeValueState::createAndAddParameter can report that they are Discrete, but they can’t override the necessary functions like getNumSteps().

Perhaps TreeValueState should be modified to allow adding param objects explicitly, instead of using createAndAddParameter.

Alternatively, perhaps a Parameter could return a reference to its associated NormalizableRange, and NormalizableRange could encapsulate some of the Discrete and Bool flags.

-Ben

9

In JUCE’s hosting code we already check for the boolean flag for AU parameters, however we don’t currently do the same for VST. This is something that can be added to JUCE though. There’s nothing similar available via the VST3 interface.

getNumSteps is already based on the interval of the normalisable range:

10

Oops, you are correct, sorry!

It’s still not clear how this should be published to a VST(2) host. I guess some experimentation is required.