Link two o more sliders

I want different sound patches playing simultaneously to have the ability to control some parameters individually or collectively (without having to add a subsequent master for each parameter).

These controls are obviously identical, so I think the best way is that I could bind them so that any change to one of them is reflected immediately in the others (I would like to see the change in real time).

I have some ideas to do it, but I think they are too convoluted and maybe there is an easier and more efficient way.

You could use getValueObject() and have them all share the same value source?

1 Like

I forgot to mention that I want to be able to link and delink interactively (via an additional button or other system).

I was thinking of doing it in the most logical way by get and setvalue from an onValueChange function, but I’m not sure if it’s the best

as the man said, getValueObject()

I have faced this issue in the past and have decided to implement the logic of it only at the UI level.

That means, that when the two Sliders are linked, then there’s a listener registered for both, that listens to user changes to one of them and reflects them to the other, as if the user had interacted also with the second one.

Each Slider controls an underlying parameter, and I have thought about implementing the LINK at parameter level, i.e. when one parameter value changes, the other does too, and that change is reflected to the respective Sliders in the UI.

But such an implementation is source of potential conflicts, like in this case: if the two parameters are automated parameters, and there’s a different automation profile recorded for each, and the LINK is active, what should happen?
Is Param1 more important than Param2, and thus the automation for Param2 should be ignored in favour of what Param1 is doing? Or the opposite? Or in that case the LINK is to be ignored?

By implementing the LINK it at the UI level, the fact that it only applies to user gestures is explicit and well defined, and it plays no role if the same parameters are moved by automation or MIDI, for example


should getValueObject be used like this?

volumeB.getValueObject().referTo( volumeA.getValueObject() );

Now they are connected on the interface, but it’s just an illusion. The volume remains independent as if nothing had happened.

I don’t know what this is for. maybe I should update the raw values manually?

I don’t know what advantages this would have over volumeB.setValue( volumeA.getValue());

It sounds logical at first glance, but it can easily happen that one parameter is set to automation latch and the other to automation read. In which case you get immediately inconsistencies, and the user is not notified, the link knob lights as if all is well…

Maybe you could flash the link button as soon as the parameters go out of sync. But that’s on the symptom, not at the root cause.

Having said that, meta parameters are a PITA…

Could you please elaborate on what inconsistencies does this scenario lead to? I feel particularly slow today and I fail at figuring out the behavior that follows from your premises

Sure, let’s assume you have a linked left gain and right gain.
The linking is handled in the GUI.
If the user moves left gain, right gain moves with it.

In many DAWs you switch the automation per parameter. So the user switches automation on left gain to latch, but leaves the setting on the right gain on read (default).
What happens: the user records an automation with the left gain, which is recorded. But the right is no longer moved, because the host automation won’t allow it.