I have been exploring the new (i.e. Juce 5.4) AudioProcessorValueTreeState
, following the steps outlined in the Saving and loading your plug-in state tutorial. (So NOT using the createAndAddParameter
method, but instead using the new AudioProcessorValueTreeState
constructor with a ParameterLayout
.) Got the basics working in a demo, and then started trying to implement an APVTS in an older plug-in that hadn’t used a value tree at all (was previously using the addParameter
method).
What I’m wondering about now is the best practice for accessing the parameter values of the APVTS from within the PluginEditor. (In this case it happens to be from within the paint
method.) There are at least three ways I can see to grab parameter values from there:
valueTreeState.getParameter("foo")->getValue
*processor.fooParam
fooSlider.getValue()
(This is assuming that the params are set up like in the aforementioned APVTS tutorial. That is, fooParam
is a Processor member set up as a pointer using getRawParameterValue
, and fooSlider
is an Editor member connected to its corresponding APVTS parameter via a SliderAttachment
.)
So which of these three is the best way to grab a parameter value from within the Editor? “Best” as in ease of implementation, but also “best” as in following the intended JUCE design pattern.
If you’re reading along closely, you’ll realize there’s a couple oopsies in options 1 and 2.
For #1, that would actually return the normalized 0-1 value rather than the “full-range representation”, so you’d also have to use RangedAudioParameter::convertFrom0to1
to make that conversion.
For #2, the Editor can’t access fooParam
if it’s set up as a private member of the Processor, as shown in the tutorial. Only works if fooParam
is made public. But apparently those “RawParameterValues” are the most efficient way to access a value, since it’s the recommended way to grab parameter values from within the processBlock
.
#3 seems the most immediate way, since Sliders are already Editor members. But Sliders are tied to parameter values via the Attachment classes, the full nature of which I don’t really understand, so I’m not sure if there are some caveats there. Plus getting data values via GUI objects seems weird, rather than going straight to the source. Also, what if you had some parameters in your tree without corresponding GUI components at all?
Thanks for considering this issue. C++ is not my native language so please pardon any coding blunders I may have made within.