Request for AudioProcessorValueTreeState::removeParameter

Audio Plugins
1

Hi Jucers,

I’m currently studying the AudioProcessorValueTreeState and thinking about to add the AudioProcessorParameter as properties in my next projects. It seems to have some good features with the widget connection stuff, undoManager and so on.
But what I miss is a removeParameter method in the AudioProcessorValueTreeState and an option to don’t add the parameter to the processor on create - then I could use the nice features additionally for dynamic parameters which I don’t like to have available in the host, but on the UI and with undo functionality like for the static params.

Here we need a new function or a option.

AudioProcessorParameter* AudioProcessorValueTreeState::createAndAddParameter (String paramID, String paramName, String labelText,
        NormalisableRange<float> r, float defaultVal,
        std::function<String (float)> valueToTextFunction,
        std::function<float (const String&)> textToValueFunction
        bool addToProcessor = true) // Request A
{
    // ...
  
    Parameter* p = new Parameter (...);
   
    // Request A
    if(addToProcessor)
    {
         processor.addParameter (p);
    }
    return p;
}

And this could be the remove method in AudioProcessorValueTreeState, here we need also a remove method in AudioProcessor.

void AudioProcessorValueTreeState::removeParameter(AudioProcessorParameter*p)
{
    // Also not implemented
    // Request B
    processor.removeParameter (p);
    delete p;
}

Or do I miss something? Can I remove a parameter from AudioProcessorValueTreeState?

Thanks

2

Removing parameters from the processor isn’t very useful as most plugin formats restrict dynamic changes to the parameter list. Changing the name seems to be possible with some formats but I haven’t managed to successfully tell a host that the amount of parameters has changed.

Adding parameters to a AudioProcessorValueTreeState object without adding them to the processor would go a bit agains the class’ name although I see the convenience for adding ‘invisible’ parameters.

3

To add a state independent of the host there is the AudioProcessorValueTree::state, which is a “normal” ValueTree. You can use the same undo manager on this, save the state in AudioProcessor::getStateInformation(), and so on.
And because the various GUI attachments work only on parameters, I did some attachments for GUI elements to “normal” ValueTrees, see:

There you have all freedom to add, remove or do anything to your “parameters”, because the host doesn’t know…

(btw. free to use, open and not open source, no claims from my side)

1 Like
4

@ Daniel:
Yes, this could be a solution (and I’ve already seen and checked out your stuff - good work), but it would be more handy to use the AudioParameters for all type of properties and handle all by the same way. Or is this possible? (maybe we can make a call in the next days - bin aus dem gleichen Lande :wink:)

@ ckhf:
Yes, you are right. An abstracter version of AudioProcessorValueTreeState without the processor dependency but with the comfortable features for AudioParameters would be nice. Seems I’ve to make a copy of the current solution and have to split it for my plan. Or any other suggestions?

5

actually I see it the other way round, in my plugin I have hierarchical settings, like a whole scenegraph to select. This would be too complicated to be presented in a float, so I have the combobox, which lets me select of a branch of the ValueTree. So having the freedom to hierarchical arrange my state gives me more liberty than just using scalar values. I see the state tree as addition to the automated parameters…

maybe we can make a call in the next days - bin aus dem gleichen Lande

always glad to meet fellow countrymen here… just PM to exchange skype contacts, or if you’re in Bremen let’s meet in a pub after work… Alles Gute!