Value Tree State SliderAttachments vs sliderthatwasmoved


I’m fairly new to this, so forgive me if this is a stupid question!

I’m trying to create a plugin. I have used the Juce GUI Component, that creates a plugineditor template for you. I have also implemented the Value Tree system.

I’m not sure of the best way of handling changes to variable through slider movements…

So. I’ve created a public variable called Gain, in my pluginprocessor.h. I want to change this value.

When I add a slider for Gain using the subcomponents tab in the GUI Component, the template adds the following to plugineditor.cpp

if (sliderThatWasMoved == GainSlider)
//[UserSliderCode_GainSlider] – add your slider handling code here…


Which of the following is the best way of handling changes.

  1. Ignoring the attachment and simply putting the following in the [UserSliderCode_GainSlider] section in plugineditor.cpp
    i.e. processor.Gain = GainSlider->getvalue();

I guess this makes setting up the Valuetree pointless and misses the point?

  1. Putting the following in the [UserSliderCode_GainSlider] section in plugineditor.cpp
    processor.Gain = myValueTree.getRawParameterValue (“gain”);

Or some variation of this, because I currently can’t this to work because myValueTree is stored as private in the processor cpp. So I’m not sure how to make that work unless I make myValueTree public? Which is inadvisable right?

  1. Handling any changes to gain in processor.cpp with code like

Gain = myValueTree.getRawParameterValue (“gain”);

But then there the whole sliderthatwasmoved section from the editor.cpp is redundant, and this seems inefficient?

Please let me know your thoughts or if there is a better of doing this that I haven’t managed to grasp.

I would encourage you to use the AudioProcessorValueTreeState::SliderAttachment.

Have an instance in your processor. You are right, the traditional OO is, that having public variables defeats encapsulation. In this case you would implement a getter to the state like:

AudioProcessorValueTreeState& MyProcessor::getState()
    return treeState;

But personally I think, since the AudioProcessorValueTreeState encapsulates it’s members, and the assignment operator is disabled, it would be ok for me to have the state public. But this is really personal preference.

Now you can add attachments in the editor. Here the members:

    //[UserVariables]   -- You can add your own custom variables in this section.
    MyProcessor& processor;
    OwnedArray<AudioProcessorValueTreeState::SliderAttachment> attachments;

And in the Constructor of your editor:

//[Constructor] You can add your own custom stuff here..
attachments.add (new AudioProcessorValueTreeState::SliderAttachment (processor.getState(), "gain", *gainSlider));

That is enough to have the slider connected with the parameter in your processor in both directions. You can untick in the Slider SubComponent the “callback”, it is not needed (the Attachment is a SliderListener).

In your processor you have the choice, either in the processBlock read the value each time:

auto gain = *treeState.getRawParameterValue ("gain");

or make it a AudioProcessorValueTreeState::Listener and implement a callback, e.g. if you need to recalculate something on value changed like new coefficients for a filter…

Hope that points you a bit in the right direction…

This is very helpful thank you!

I do actually need to recalculate some filter coefficients, so would you mind elaborating on implementing a callback via a ValueTreeState::Listener?