Assigning a new parameter to an existing GUI slider?

Hi, my plug-in needs to have different parameters associated with a set of GUI controls.
So I need to reassign SliderAttachment’s to different parameters when I want to.
Does anybody know how I do that? I can’t figure it out. Do I just delete them when I need a change? That seems wasteful, and unsafe.
I currently keep all my sliders in a…

OwnedArray <AudioProcessorValueTreeState::SliderAttachment> sliderAttachments;

Based on the API here: https://docs.juce.com/master/classAudioProcessorValueTreeState.html you should probably not add/remove parameters on the fly.

Use some other logic to setVisible(true/false) your sliders as needed. I’m pretty sure that hidden GUI elements don’t receive mouse events so you don’t have to worry about if a slider that shouldn’t receive mouse clicks will receive those mouse clicks. but it’s super easy to test…

1 Like

I have 60 different selectable objects that will use the same 6 controls at different times. I’m not sure that creating all those gui elements is the best way of doing it - to make the unused ones invisible? Seems a little crazy to me, but maybe I’m old fashioned.
Thanks for answering.

IMHO both ways should work and I see no problem with either one. In terms of resources it will end up the same. A hidden Slider doesn’t eat CPU, except setting the variable “current value”.

I would base my decision on code simplicity:

  • if the sliders appear to the user as generic controls, I would delete the attachments and create new ones, the GUI code is not affected
  • if the GUI could be different panels depending what setup was chosen, I would write a separate GUI for each setup, with the appropriate descriptions for each settings, so I can switch the GUI with a single line and don’t have to worry, that the right description to the right attachment is displayed.

But it’s a many-ways-to-Rome case.

2 Likes

Thanks Dan. It’s a shame I can’t just reassign an existing attachment, that would be better- so I can run through them and say “you were looking at that parameter but now it’s this one.”

I’m going for the create everything and show what’s needed approach. I was a little worried about the time spent looking up parameter names. But it’ll be fine, I’m sure they’re all hashed anyway. :slight_smile:

Not really, it works differently. The attachment is a listener to the component, so no lookup is needed. And on the other hand, they are parameterListeners on the AudioProcessorValueTreeState (and internally bound to a parameter in the tree, also no lookup needed).

But you can use that for your attachments, if you want easy access:

std::unordered_map<Component*, std::unique_ptr<AudioProcessorValueTreeState::SliderAttachment>> attachmentMap;

// link
attachmentMap [&slider] = std::make_unique<AudioProcessorValueTreeState::SliderAttachment> (state, "paramID", slider);

// unlink:
attachmentMap.erase (&slider);

Haven’t tested it, but should work…

I’m just getting " ‘unordered_map’: is not a member of ‘std’ " which is odd.

it needs an include, see cpp-reference.com

#include <unordered_map>

Nice, thanks man. I’ll have to find out more about that…