I need to be able to assign widget pairs in a script.
I need more links than there are letters available. 
As you can react to widget changes and can modify another widget accordingly, I suppose that it is doable.
But why don’t you share your use case, sometimes other solutions arise from discussions in this community forum…
Well, it is doable in the sense that you can catch an on widgetvaluechange event and set the other widget’s value accordingly. But the problems arise when you want this to happen bidirectionally - if you also do the same trick in the other direction, you get a loop, which sometimes leads to quirky behavior like widgets jumping superfast, and eventually GP hangs or crashes.
My use case…
I have rackspaces with various guitar plugins and a ton of widgets to control them - amps, pedals, all that stuff, and I want to use a hardware controller to adjust settings quickly.
But there are many more controls than my controller has knobs.
On the other hand, those controls are somewhat similar across plugins and rackspaces - they all have gain, bass-mid-treble, presence, a graphic eq etc. So I want the same knobs on my hardware controller to adjust those settings on all rackspaces/plugins.
The hardware controller in question is a Behringer X-Touch Mini, so it has 16 encoders and 48 buttons.
Mapping this to every rackspaces is also kind of stupid and boring, so I thought maybe I’ll use global rack widgets that are synced with the same set of mirroring widgets on a panel in each rackspace, then that stuff would turn the actual plugin-controlling widgets.
Hope that makes sense.
That’s true, you have to block this kind of loop incrementing a variable each time you modify a “linked” widget. The “linked” widget callback will in turn be called and in the callback, you will have to check the value of the variable. You can only modify the “linked” widget if the value of the variable is zero else you have to decrease it instead.
That’s indead a solution:
2 Likes
I wish. That’s what I tried to do at first, but the problem is that it’s in fact for widgets in local racks to control widgets in the global rack.
Because you have to map the local widget to the “from global rackspace” plugin which renders it useless.
I’m not sure who would ever want to control global plugins from local racks and why it is designed this way, but it is what it is.
Or maybe I’m missing something.
So do in fact use that mechanism to link global and local widgets. So they are synchronized. But that by itself is useless, those local widgets don’t control anything and mapping to a plugin is occupied.
That’s why I’m trying to link them with widgets that actually control things.
Of course I tried to catch On WidgetValueChanged and then call SetParameter to control the plugin directly, but the damned plugin doesn’t return the changed parameter value, so the widgets that actually control the plugin don’t reflect the changes, and therefore I can’t save variations, everything gets reset when switching rackspaces.
Hm, I’ll try to digest it, thanks!
Sorry, I fail to understand 
So I have widget A and widget B
A changes, callback is triggered and what do I then have to do with the variable?
I use Bome MIDI Translator Pro and use gestures (single tap, tap and hold, double tap etc.) To change what the buttons send. I can also create presets in Bome MIDI Translator Pro to extend the number of functions even more. The gotcha is that you need to use a control to change between presets so it may not be as efficient since it requires another action to move between presets.
SteveC
@SteveC-Bome yeah, I was thinking about something like that. But for now I want to avoid more complexity and buying new software.
Gotcha, you might be able to do something regarding layering in scripting as well. Still more complexity but less costs if you know how to script or someone does it for you for free.
SteveC
Scripting as such isn’t that big of a problem
A lot of things are just too confusing in GP. “Global parameters” aren’t really parameters, an article about controlling local racks from global is actually about controlling global from local, BindWidget doesn’t bind anything… All of this takes too much time to figure out through trial and error
Then maybe a different controller with more controls is the thing, but again that would cost money but perhaps reduce complexity.
Perhaps though more knobs and buttons is not good for live performance. Maybe have different RackSpace variations to control a series of widget parameters by just changing to a new variation. Kind of hard to fuss with a lot of knobs during a live performance.
Widget A increments a variable and modifies Widget B
Widget B callback is triggered, it checks the variable, if it is greater than zero it only decrements the variable else it modifies Widget A in turn.
I hope it is more clear. 
2 Likes
What exactly?
Of course they are, why do you say this?
It does if you use it the right way, but why do you want to use GPScript here?
This is always going to pose a challenge, if you do want the ability to adjust settings on the fly.
You will likely need to consider a controller better suited to doing this, or something like a tablet with TouchOSC, where you get the benefit of bidirectional syncing and the ability to define as many widgets as you need.
2 Likes
This is actually on our list to improve for a future version.
If you have to manage so many controls in real time, then you may want to consider using a controller that has more controls. Though it can help, GP Script wasn’t really designed to let you compensate for not having the necessary controllers needed to achieve your musical goals.
Typically the global rackspace is used for final processing such as effects like reverb, phaser, volume. You might have controls on the global rackspace to adjust such things as reverb length, the phaser depth, rate, on/off and so forth. Then in your individual rackspaces, you can control those global widgets from your local widgets and in particular, when you switch to a specific rackspace, the local widgets in that rackspace that are mapped to widgets in the global rackspace will automatically set the global values needed for the rackspace. That is why it is designed like that.
At what point? During creation of your gigfile or during a live performance?
What global parameters? Do you mean Global Widgets? Global Widgets are exposed to rackspaces as actual plugin parameters via the “To Global Rackspace” plugin. That is why one can map widgets to them.
Which article?
1 Like
No, a controller with more knobs is the opposite of what I need. I need a limited number of knobs where everything is always in the same place and doesn’t change.
Like, knob 1 is always amp gain, and pressing it is gain boost. knob 5 is treble, and pressing it is treble boost, regardless of a stupid name the specific plugin manufacturer gave it, like “air” or “bite” or some such nonsense. knob 8 is always reverb mix.
Then I want to consolidate the various pedal plugins and again, have the same knob to control “mix” for all of them, regardless of whether they call it “mix” or “dry/wet” or something else.
I need global parameters, in other words. And a very limited set of hardware knobs to control them.
During performance, or rather during setting up sound for another place. To be able to quickly change stuff if it’s too bright or too wet or too gainy. Plugins sound like ass, and made to impress through headphones/in recordings, it’s always some struggle to make them sound decent through a PA system.
The problem is that to use the global parameter feature I need to map widgets to a plugin, which makes the widgets fairly useless. So they aren’t controlling any parameters in the end except turning themselves in sync with some other widget.
That’s how I use the global rackspace, too, except reverbs and phasers and such are in local rackspaces due to how guitar plugins are made.
Anything in the global rackspace is easy to control without any shenanigans.
But thanks for explaining.
This article How to control widgets from the Global rackspace in a regular rackspace?
I certainly don’t need a screen to control another screen. 
It is, thanks a lot!
1 Like
Not at all. Global widget can control other Plugin parameters and are also exposed to the local Rackspace widgets as parameters. Read you article again, it is a nice one as it is the GP manual.
It’s a bit of a mockery. Many users find it quite practical to design a live manipulation-oriented user interface on a responsive touchscreen.
What is described in that article is the setup I have.
Local widget needs to be mapped to a plugin like From Global Rackspace where those global “parameters” are exposed. So that local widget can’t be used anymore without scripting.
Global widgets indeed can control things, but I can map a hardware controller to them directly, I have no need for local widgets to be linked to them.
This whole setup scheme works in one direction only. It doesn’t work for controlling local parameters by global widgets, which is what I need.
I realize that people find all kinds of things practical, but it is not at all practical for me. I have a screen with all controls on it, and can manipulate them there. If I wanted a touch screen, I’d buy a Windows laptop with one, plain and simple.
I want to minimize the number of controls visible at a single point of time, have them always in one place regardless of a plugin being used, and even if I went the OSC/tablet way, I’d still need to implement the logic that would switch onscreen controls based on which rackspace is loaded and its settings.
And if I do it, of course it’s better anyway to have a hardware controller with tactile experience, which can be manipulated without looking, then a touchscreen.
I did use those touchscreen OSC thingies for some things - like monitor mixers for all band members using sound card’s functionality, for example. So they do have their place, it’s just not the use case I have
Your solution seems to work like a charm, so again thank you so much for the suggestion! I used an array instead of one variable to make sure it works even if several controls are changed at the same time, but other than that it’s a great and simple solution.