AudioProcessorParameterGroup - need unique paramid?

Hi

Im trying to use parameter groups as a way to keep parameters names ‘sensible’
e.g

AudioProcessorValueTreeState::ParameterLayout PluginProcessor::createParameterLayout() {
    AudioProcessorValueTreeState::ParameterLayout params;
    {
        auto ts = std::make_unique<AudioProcessorParameterGroup>(ID::input, "Input", ":");
        ts->addChild(std::make_unique<AudioParameterFloat>(ID::pan, "Pan", -1.0, 1.0f, 0.0f));
        params.add(std::move(ts));
    }
    {
        auto ts = std::make_unique<AudioProcessorParameterGroup>(ID::output, "Output", ":");
        ts->addChild(std::make_unique<AudioParameterFloat>(ID::pan, "Pan", -1.0, 1.0f, 0.0f));
        params.add(std::move(ts));
    }
    return params;
}

I was expecting this to create unique parameters ids, something like input:pan output:pan

but I find AudioProcessorValueTreeState is tripping over in add ParameterGroup

void AudioProcessor::addParameterGroup (std::unique_ptr<AudioProcessorParameterGroup> group)
{
    jassert (group != nullptr);

    auto oldSize = flatParameterList.size();
    flatParameterList.addArray (group->getParameters (true));

    for (int i = oldSize; i < flatParameterList.size(); ++i)
    {
        auto p = flatParameterList.getUnchecked (i);
        p->processor = this;
        p->parameterIndex = i;

        checkForDuplicateParamID (p);
    }

    parameterTree.addChild (std::move (group));
}

checkForDuplicateParamID fails… since Pan, is already created.

does this mean I explicity have to create my own parameter namespace?

if so Im not quite sure what the use of ParameterGroup is…
is it just a nice way to group parameters for a host?

EDIT: just tidy up my example a bit

The main purpose of AudioProcessorParameterGroup is to allow the host to group related parameters together when displaying them to the user (e.g. in automation or MIDI mapping menus). It won’t modify paramIDs, so you must use some other technique to ensure that all of your parameter IDs are unique.

1 Like

ok, I guess the host only sees the parameter name, so thats ok…

so just change the id, leave the name the same

AudioProcessorValueTreeState::ParameterLayout PluginProcessor::createParameterLayout() {
    AudioProcessorValueTreeState::ParameterLayout params;
    {
        auto ts = std::make_unique<AudioProcessorParameterGroup>(ID::input, "Input", ":");
        ts->addChild(std::make_unique<ssp::BaseFloatParameter>(ts->getID()+ts->getSeparator()+ID::pan, "Pan", -1.0, 1.0f, 0.0f));
        params.add(std::move(ts));
    }
    {
        auto ts = std::make_unique<AudioProcessorParameterGroup>(ID::output, "Output", ":");
        ts->addChild(std::make_unique<ssp::BaseFloatParameter>(ts->getID()+ts->getSeparator()+ID::pan, "Pan", -1.0, 1.0f, 0.0f));
        params.add(std::move(ts));
    }
    return params;
}

do all hosts support parameters groups? including older ones?
if not, what happens? do they get unique parameters names?

I guess, what is kind of confusing me is… why does the parameter group need the separator if its not doing any kind of flattening of the name space?

No, some hosts may choose not to display groups at all and may display a single flat list. Lots of the more well-known hosts support groups in some capacity though.

Different plugin formats have varying levels of support for parameter groups. As an example, AU plugins can only understand a single level of nesting. In cases where the requested grouping is unsupported by the plugin format, JUCE will automatically flatten the parameter groups using the provided separator to demarcate the inner groups. There’s some more information in this thread.

1 Like

thanks, ok… I can see its really just a way to tidy things up for hosts…
and they can choose to ignore if they wish, since the parameter id is still unique.

btw: Ive just noticed the example AudioPluginHost does not display parameter groups, this might be a useful place to add an example.

thanks for your (very swift) help., really appreciated :+1:

(I’m using AudioPluginHost alot at the moment, since its the only host I have that supports Apple Silcon VST binaries!)