Is it possible to link widgets programmatically?

Scripting with Gig Performer
21

It seems to me that you don’t need the Global Rackspace for what you plan to do. I my Rig, I use some controls for almost always the same thing, but only almost. So I have a rackspace template where my controls are already mapped to widgets. When customizing the Rackspace I set to the widgets to the proper parameters. That’s it.

For more complicated thing like, e.g. controlling a GP 32-mixer plugin with an 8-fader control surface, I use GPScript with the kind of programming tricks I exposed to you. I also use the OSC communication and I bind widgets of the Global Rackspace dynamically.

1 Like
22

I need the global rackspace very much

It has streaming players and controls for backing and cue tracks, 4 looper instances and controls, some sound correction and output measuring, a bunch of fx for vox - gate, de-esser, eq, compressor, saturation, stereoizer, chorus, delay, reverb, a bit of guitar processing - mainly volume pedals, and a mixer for it all. Also some scripting is there and in the gig script. Like, watching for song part changes and updating LEDs on the footswitch (another controller).

None of that has anything to do with local racks though, it’s just stuff that’s common across all songs, and I have a Korg Nanokontrol to deal with it. It’s the easier part though because everything is mapped directly and doesn’t change.

If I need some peculiar effect occasionally, I’ll just modify a standard guitar rackspace and add it there, all audio inputs are routed through the global rackspace, then it’s sent to local and comes back again to global and then the outputs.

23

I plan to have something similar except guitar plugins have dozens of controls, and a lot of them are quite different. I have something that may be called a template for that. The problem is then taking all that variance and grouping it so that no more than 8 knobs do the stuff - like one controller bank does all Amp controls for any plugin, another one does eq, yet another one does individual pedals one by one. Like press a button to select an overdrive pedal, have the typical overdrive knobs - drive, tone, level - on the same controller knobs always.

I want to create a standard panel with widgets mapped to global widgets mapped to hardware, and then customizing a new rack would be adding this panel, including some common script coding and mapping some local widgets plus doing some local variable declarations.

24

Indeed. The thing is, people want their hardware controllers to control different things depending on what they’re doing and so mapping a hardware controller to a widget in a local rackspace allows different parameters to be controlled from the same hardware knob depending on the rackspace.

Actually, it’s pretty easy to set that up using Direct Addressable OSC. Here’s an example gig file where a global widget is controlling a widget in a rackspace and when you change the rackspace, the same global widget will control the widget in the new rackspace.
OSCGlobalLocal.gig (411.9 KB)

1 Like
25

Hm, nothing works in that gig file, I probably need to set something up in my local GP?

26

Well, you have to turn on OSC and set the listening port. I assumed based on the depth of your previous comments that you would know about OSC as well

27

I have it on, but my exposure to OSC is limited and very dated (it was years ago that I touched it).

But I’ll figure that out, thanks for pointing me to what needs to be done.

28

I’m not at my computer now bu look at the setting for the port in the configuration of the global widget and set GP to LISTEN on that port, then it should work

1 Like
29

Yes, that worked. And the approach looks promising.

Thanks a lot again!

1 Like
30

Ok, while it wasn’t the reason we added OSC support, it can certainly be used that way. Also, though it’s generally not a good idea, you can directly control plugin parameters via OSC as well so you don’t need local widgets….but it’s easier to use local widgets to simplify mappings

31

Since a lot of plugins don’t update GP on parameter change events, widgets on the local rackspace aren’t updated, and therefore snapshots of variations can’t be saved properly. So I need to go the widget sync route.

After playing for a while with your solution though I found that it still has the same problem as the midi one - it works in one direction only (now the correct one for me :slight_smile:, but I need things to happen the other way around, too - when song parts are changed I need my controller to reflect that.

So I configured the route from local to global, and it worked for a while but then of course got the loop condition and GP crashed. So still needs some scripting to go with it.

But it looks much tidier than the global parameter way of doing it.

32

If I may make a suggestion, a true global parameter implementation would ideally look like this for me:

In a widget property you map it to a global parameter number (ideally also with an option to choose to send absolute value or increment, and regardless of whether it’s in a local or a global rack), with or without also mapping that widget to a plugin.

Then when the value of that widget changes, it is changing the value of that parameter.

Then any widget anywhere can read or write to that parameter value (could also be an option to make it read only), no scripting shenanigans needed.

So it all can work like it’s a truly global parameter setup, similar to how it’s implemented very usefully in some hardware - e.g. Axe-FX. There you have global reverb mix, for example, which works as an offset - all patches that have reverbs will have mix adjusted up or down when you change the global value, so you can easily and quickly accommodate to different room acoustics.

33

I’m not sure this is at all useful to you, but there are aspects of what you want to do (I think) that are similar to what I do and wanted to do using various controllers of my own.

The first controller I did this with was Behringer controller (BCF-2000) that emulated a Mackie MCU. To get this doing what I wanted I created a GP extension that uses the MCU protocol. (MCU Protocol Control Extension - GP Extensions - Gig Performer Community)

The various Behringer xtouch controllers since then have all (as far as I know) implemented the same Mackie MCU protocol.

The learning curve on setting that up and using it isn’t trivial, and it’s frankly way overkill for what you’re doing. But if I understand what you want to do correctly, it may make your life easier because it already takes care of the synchronization of widgets, etc.

Keeping things real simple, let’s say you have 30 different rackspaces that all have some version of a “gain” knob. Let’s say you always want that on the first knob.

If you have that extension loaded, and you always want that gain knob linked to the left-most knob on your xtouch-mini then you just have to go into each rackspace and assign that knob widget a specific name. The extension will take care of the rest.

If it sounds like it might be useful, take a look at that MCU extension thread I linked.

1 Like
34

Hm, that sounds very interesting indeed, I’ll definitely take a look, thanks a lot!

The main problem I see with it is that the mini has only 1 “layer” in MCU mode, so cuts the number of controllable parameters in half (without additional scripting).

35

Maybe. I don’t know how the mini works in MCU mode. If the layers don’t do anything at all then yeah, that would be a problem.

The extension is written such that you can have an unlimited number of “banks” of knobs. With a real MCU there is visual feedback available to indicate which bank of GP widget knobs are currently linked to the physical knobs. Not sure if there’s an easy way to do that with the mini.

36

The mini has 2 buttons, labeled A and B, for switching between “layers”, or banks. And these buttons have LEDs to indicate which layer is selected. Changing layers changes which CCs or notes are sent when you press buttons or turn knobs. But that’s in “normal” mode.

In MCU mode layer switching doesn’t work, the A and B buttons don’t send anything, and their LEDs aren’t accessible.

Right now I plan to use the 2 layers and will also use 4 if the regular buttons to switch between “modes” - 2 layers of amp controls, another mode for EQs, third mode for FX on/off, fourth mode for FX tweaking, both in local and global racks.

I also want the fader to control whatever widget was touched last, for fine tuning if needed.

For visual feedback, I’ll have the A and B buttons, and also the buttons I dedicate to “modes”

The way I did it with the footswitch is different - it doesn’t have any layers, so there I have a gig script which detects long press and then rewrites the channel from which CCs are sent, emulating another controller, to switch between either changing song parts (which I use as presets/patches) or looper control. There’s no visual feedback on the footswitch to indicate which mode it is in except I blink all LEDs when switching between modes happens, and the LEDs behave differently.

So yeah, lack of feedback is a bit of a problem, but maybe not too big of a deal. Lack of banks, on the other hand, is.

I don’t know how controllers interact with extensions, maybe it would be possible for a gig script to intercept the comms and fake channels to emulate banks, too?

37

This was a journey and a lot of hurt chasing the “array index out of bounds” errors with no way to trace which array exactly caused this (the log says “Check GPScript Settings” - which settings?), fighting those feedback loops (the solution offered here by @David-san worked locally, but not so well with OSC, so I had to implement different logic for buttons and knobs), doing extra typing (why, oh why the “From” part of callbacks can’t accept variables?), I finally managed to implement dynamic linking across rackspaces to have global parameters the way I need them to work.

@dhj can we please please have global parameters that don’t require mapping widgets to plugins, but rather using a pub/sub model of sorts? With SetGlobalParameterValue, GetGlobalParameterValue, On GlobalParameterValueChanged or some such?

38

@dhj will tell you that GPScript was never thought to be a development tool… but the beast escaped :stuck_out_tongue_winking_eye: There is no GPScript debugger so, the idea is to Print what you want to check. An array index out of bound is probably not the more difficult bug to track. :wink:

I use the trick a lot with OSC too and it works very well.

39

Efficiency in a real-time system.

40

It makes includes very limited though, so for all rackspaces I have to create their own versions of the script, instead of writing it once, which is a bit tiresome, not to mention error prone. And maintaining multiple scripts, making sure any changes are propagated everywhere, seems to be a challenge. :frowning:

I looked into the SDK, and possibly I missed something big there (I could :smiley:), but extensions seem to be mostly limited to the same stuff as the scripts are. Meaning, you still have to add those pesky handles to widgets to access them, events are basically the same, so not sure how moving the logic to an extension would make things better really. :man_shrugging:

Am I wrong here?

But how??? Your trick, as I understand it, basically skips a step, which is more or less fine for knobs most of the time, but doesn’t work for buttons. Plus when used locally things are super fast so syncing is very smooth, but when some latency is involved movement becomes a bit erratic.

Can you please provide a snippet of code where you use it with OSC? :pray: