BUG? SliderParameterAttachment

General JUCE discussion
1

In the constructor of SliderParameterAttachment there is:

slider.setDoubleClickReturnValue (true, param.convertFrom0to1 (param.getDefaultValue()));

This allows for the default argument of an alt key modifier.

If you change this prior to linking the slider and the attachment, it is overwritten here.

I suggest adding more granularity here to allow just the reset value being changed, rather than the entire configuration.

Imagine you have a sub classed slider with all the behavior you want set in it’s constructor. If you then add one of these attachments, you have to repeat yourself after linking.

2

the default value of a parameter is owned by the parameter which is owned by the audio processor. that is why the parameter attachment reads it from the parameter rather than a value that is part of juce::Slider. But I agree more customization features would make this class much better. For example here we could imagine an argument in the ParameterAttachment constructor for wether the slider should use this feature at all and if yes, on doubleclick and/or on some modifier key, in which case which one

3

Consider moving this configuration in a free function instead of inheriting Slider. The gives much more flexibility:

juce::Slider slider {juce::Slider::rotaryHorizontal, juce::Slider::NoTextBox };

void setup (juce::Slider& slider)
{
    slider.setWhatever();
}

attachment = std::make_unique<juce::SliderAttachment>(parameter, slider);
setup (slider);
4

I don’t believe there is any need for more customisation by bloating the current classes with more stuff.
This part of JUCE is software architecturally perfect in my opinion and offers plenty of customisation options. It is a very strong and simple to use MVC pattern:
Model: Parameter
View: Slider
Controller: Attachment

You can customise any part of it by inheriting or replacing one of the three stages yourself. I think customisation-wise, this is as good as it gets and as good as it should be.

For this problem, I can think of several options to implement the desired behaviour depending on what it is actually:

  • You can alter the parameter to return a variable default value, instead of it being constant.
  • You can write your own attachment to setup the basic slider the way you want
  • You can alter the slider to consume double click events (essentially a slider that does not offer to be double clicked) or change the way a “double click” or any other behaviour might be executed (having accessibility in mind for example).
5

keep in mind a plugin’s default patch is typically not customized plugin-internally, but handled by the DAW. So even if you let users change the default value, those values can end up not popping up on users’ init patches, which would reduce the function of the default value to its slider interaction trigger. in cases like that it is often encouraged to just provide other ways to set specific values on a parameter, like text editors, snap features or nearby buttons with the most likely parameter values, for example +7, +12, +19 for pitch

6

Perhaps this would be better:

slider.setDoubleClickReturnValue(
    slider.isDoubleClickReturnEnabled(),
    param.convertFrom0to1(param.getDefaultValue()),
    slider.getSingleClickModifiers() // this function does not exist
);

I have encountered this problem before :innocent: It took me a while to figure out why double-clicking was enabled again.

1 Like