Is it valid to add additional properties to the ValueTree of an AudioProcessorValueTreeState?

1

Simple question, I’m not sure if it was already answered somewhere here :thinking:

While building a plugin with a bunch of parameters managed by the AudioProcessorValueTreeState, I need to store some settings of the plugin that are no parameters but that hold a certain state of the user interface. As a load/store operation should also store/restore those, I thought it would be handy if I just added some additional properties to the ValueTree used by the AudioProcessorValueTreeState. Like this:

MyPluginAudioProcessor::MyPluginAudioProcessor() : //...
{
    // parameters is my APVTS
    parameters.state = ValueTree (Identifier ("MyPlugin"));
    // uiState is a Identifier member 
    parameters.state.setProperty (uiState, "", nullptr);
}

// then somewhere in the code, might be in the processor or editor:
String currentState = parameters.state.getProperty (uiState).toString();
// do something with it...
parameters.state.setProperty (uiState, newState, nullptr);

A quick test with the default standalone build worked fine, however, I’m not sure if this is a dangerous hack or a safe operation. If it shouldn’t be done this way, what are best practice examples of how to store additional state information that are accessible all over the plugin?

2

Yes, the docs say so AudioProcessorValueTreeState::state:

You can replace this with your own ValueTree object, and can add properties and children to the tree. This class will automatically add children for each of the parameter objects that are created by createAndAddParameter().

I do that all the time, had no problems so far.

I don’t know though, if there are measures in place to avoid name collisions. A list of “forbidden” properties would be good…

3

It’s very elegant especially if you need to keep internal states (for example let’s say plug-in has multiple sizes or a visual theme…)