I saw this code in another forum post and it works great for what I want to do and it does it succinctly:
juce::Value valueToControl = tree.getPropertyAsValue("ID", nullptr);
slider->getValueObject().referTo(valueToControl);
However I was wondering if this is good practice. Before I made the parent of the slider derive from Slider::Listener, then implemented the listener callback to update the valuetree accordingly.
Any downsides to doing it this way?
Well there are lots of advantages to using Value objects rather than overriding Slider::Listener and i.e. calling a method of your AudioProcessor class. Perhaps most importantly, assuming the relationship between the slider and the ValueTree is simple (the slider modifies only one parameter and does so in a predictable way) it takes considerably less code to attach a slider to a value tree with a value object. It is also normally quite easy to debug and modify these relationships later.
I’m assuming that you’re talking about a plugin here, and although the pattern I’m going to mention works even if you aren’t using one, it’s definitely geared towards plugins.
The best, most idiomatic way to attach a slider to a parameter, assuming that parameter is in an AudioProcessorValueTreeState, is to use an AudioProcessorValueTreeState::SliderAttachment, which basically does what you’ve done automatically and keeps the slider and the parameter it changes in sync.
None of these ways is wrong per se, and there are moments where you will need to derive from Slider::Listener to modify parameters in some custom way, but generally if it can be avoided it reduces clutter and incurs no overhead to use an attachment.
Yes, this is for a plugin. I agree using attachments is great however I tried to use an AudioProcessorValueTreeState but I don’t think it’s suitable for my needs since I need the parameters to be invisible to the host. I’m making a synth with 4 oscilallators, each with 4 envelope parameters, plus gain paramaters, plus a matrix that I will implement soon. This all adds up to 50+ parameters which I don’t want visible to the host. Right now I don’t think the APVTS is fleshed out enough to do what I want it to do.
