Widget Grouping

I have two widgets assigned to two mutes on the audio mixer. I have a slider in this group as well to control the muting of one channel and the unmuting of the other. My question is, can I have the widget only light up when the channel is muted. Both widgets are lighting up when one is muted and the other is unmuted. This visually is confusing. Thoughts? I attached a short video.

Because you’ve linked the three widgets, they’ll have the same state. My guess is that only with some scripting this can be fixed.

Might be a nice feature request: inverted linking of widgets, although these ‘little’ things can prove to be real pain.

I wonder could these visual representations react to the scaled value (instead of the widget value).
Maybe a feature request.

That might lead to the same problem as with parameters ‘back-annotating’. From x to y is always possible, but from y to x not, when the curve has multiple points with the same y value.

I had long discussions about this subject with a former developper of GP, not sure this will change. So indeed, as mentioned by @Frank1119, in the present situation, GPScript is you friend.

Do we have any example of such a script? I’d like to index it somewhere as ‘useful stuff’ for other users.

Tomorrow night I can create that.

1 Like

This is one example among others. This one makes use of the following Scriptlet:

  value   : parameter = 0.0;
  inverse : parameter = 1.0;  
// Called when a parameter value has changed
On ParameterValueChanged matching value
  inverse = 1.0 - value;

antagonist_buttons.gig (77.1 KB)

Observe the linked widgets (link groups A and B) and the additional hidden red sliders which are also mapped to the Scriptlet parameters:




I created a new thread here: Useful scripts and Scriptlets

1 Like

Well, I promised, so I made a variant on the example of @David-san.

Main difference that Davids example leans on the plugin parameter value where my example leans on the WidgetValue. Furthermore my example shows the values beneath the indicators.

I added a second rackspace demoing with knobs instead of switch-buttons.

Update: Needed a guard to prevent feedback loops. Also added a third rackspace with a cross-fader variant (but a balance knob could do as well):

Reverse Widgets.gig (211.8 KB)


(I’m not saying that my version is better than @David-san s’. It’s different, that’s all :slightly_smiling_face:)


Just had a look at your nice solution. Yes, the main difference is that you used a Rackspace GPScript, while I used a Scriptlet. You also used two callbacks, while I think one is enough if you lock the Led Buttons Widgets (I should do it toot) and there is no possible feedback loops anymore (I am wondering if it is really necessary in you GPScript to test for it as callbacks are not supposed to be called if the value didn’t change).

I used 2 callback, for then, when using the mixer controls (especially the one with rotating knobs instead of switches), both controls on mixer do work. The feedback loop is a result of using the 2 callbacks.

Just for ‘fun’: remove the guard (in the rotary knob rackspaces) and then turn a widget or a control on the mixer. GP will freeze.

Also disable/remove one of the callbacks. Then open the mixer and use the Brass and the FM sliders. You will see that in one of the cases the sliders will not move in opposite directions, but one will be stationary.

So the 2 callbacks for making the whole thing work without unexpected behavior. The guard for solving the problems that arise from the solution.

If you get all this working without, I’m open for suggestions: The less scripting, the less potential problems. The less state, the less responsibility for maintaining state.

:beers: :coffee:

1 Like