EqualizerExample Analyzer Enable Buttons

[jos]

In the EqualizerExample, there are two convenient ToggleButton enables for the input and output spectral displays. The editor support for them is apparently added via

inputAnalysing.attachToValue (magicState.getPropertyAsValue ("analyser:input"));
outputAnalysing.attachToValue (magicState.getPropertyAsValue ("analyser:output"));

These show up as ToggleButton “value” choices analyser / input and analyser / output, right under the “parameter” choice, which is empty.

I see that “input” and “output” are the names of the analysers defined, but the “analyser” prefix is not defined anywhere I can find. Is “analyser:” an arbitrary “directory name” for the property list in the GUI editor? Could we also say something like “analyser:spectrum:input” etc.? I assume the last path element has to be a uniquely defined name, or could the property be created that way?

I assume the parameter path is created by this call, even though it says “getProperty…”, or is there some automatic analyser pathname mechanism I missed?

My guess is that a “parameter” is always an AudioProcessorParameter, while a “value” is more simply any juce::Value that can be used by the plugin for GUI configuration etc. without burdening the audio processing parameter tree.

I assume it works to drive two toggles in parallel if we set both the value and the parameter fields.

Please let me know if I am off on any of this.

Thanks,
Julius

[jos]

In looking further at the code, it appears the property names must be globally unique. That is, we can’t use “analyser:input” and “waveform:input”, for example. Please let me know if I missed something.

[daniel]

@jos

I see that “input” and “output” are the names of the analysers defined, but the “analyser” prefix is not defined anywhere I can find. Is “analyser:” an arbitrary “directory name” for the property list in the GUI editor? Could we also say something like “analyser:spectrum:input” etc.?

That is exactly the idea. The AudioProcessorValueTreeState has the public ValueTree state, and the properties are located under this ValueTree. To allow a hierarchy in the ValueTree, there is the colon notation. Each name is a ValueTree node and the last part is a property name.
You could see it like a file path, just that it uses the colons instead of slashes.

@jos

I assume the parameter path is created by this call, even though it says “getProperty…”, or is there some automatic analyser pathname mechanism I missed?

Yes it is lazily created. You call getPropertyAsValue() so you can set it to a value or use value.referTo (otherValue). The point of the property values is to have interactive connections.

@jos

My guess is that a “parameter” is always an AudioProcessorParameter, while a “value” is more simply any juce::Value that can be used by the plugin for GUI configuration etc. without burdening the audio processing parameter tree.

Yes that is exactly the point. the AudioParameters are exposed to the host, while the properties are just for the plugin’s use. And properties by itself are not thread safe to be used in the processBlock(). If you need that you have to create some form of wrapper, e.g. by using a Value::Listener and set an atomic variable in the valueChanged() callback.

@jos

In looking further at the code, it appears the property names must be globally unique. That is, we can’t use “analyser:input” and “waveform:input”, for example.

That should actually be possible. If it doesn’t work let me know, the analyser:input and waveform:input should refer to different ValueTree nodes. If there is a clash then it is a bug. I will double check.

Hope that explains it a bit.

[daniel]

I double checked, the paths inside the ValueTrees works here, so waveform:input and analyser:input would be independent properties.
But while investigating I hit an assert that the combobox is not editable. I fixed that on the develop branch and I hope to do a release soon, as soon as I finished the midi learn feature I am currently working on.