How to - Mapping a widget to the "To Global Rackspace"

Dear community

I would like to map, in a GPScript, a widget in a local Rackspace to the “To Global Rackspace”-Plugin.

I want to use the function call “MapWidgetToPlugin()”

The first parameter in the function is the pluginblock and I cannot see how to define that specific block (To Global Rackspace) in the script.
It seems that it is not possible to set a GPScript name it.

Other plugins works fine with “MapWidgetToPlugin()”

Can anybody point me in the right direction?

These widget/plugin functions can’t see outside their own rackspace.
There are a few specialised functions that allow you to reference a widget in another rackspace (e.g. SetExternalWidgetValue), but there are only a few available like this.

Arh ok.

So what you are saying is that even though the plugin “To Global Rackspace” resides within the Local Rackspace, wherefrom the script is running, it is not really part of it but belongs more to the Global Rackspace?

That explains of course why it is not possible to assign a GPScript name to the plugin.

Why ?

I misread your original post - I thought you were wanting to map a widget directly to a plugin in the global rackspace (I didn’t pick up that you were trying to do this via the ‘To Global Rackspace’ plugin).

I have never tried this, but can see the ‘To Global Rackspace’ plugin can’t have a GPScript handle defined for it, which would be needed for this to work.

1 Like

Well the reason is a bit within the “automation” and “comfort” category :slight_smile:

I have an 8 channel mixer in the Global rack.
For each local rack I have as a standard quite som widgets linked to the Global rack, such as volumes sliders, effect sends, gain, balance, mute, open/close editors etc.
At the same time the visible layout is very different between the global and local racks, as the local rack really only has very small knobs (to be hidden behind a shape during operations).
So the possibility to copy widgets directly from the Global rack will anyhow take a lot of formatting.

Thus I am left with a standard “empty” rack I duplicate to concrete “music” racks.

It would hovever be nice to have the option to copy/paste the global-rackspace-linked widgets directly from one local rack to another.

I know though that the mapping to the Global Rackspace is lost in this process.
That was where I thought the function, such as “MapWidgetToPlugin()” would come in handy.

With this I can make an automated mapping of all relevant widgets quite easily so that creation and maintenance of local rackspaces would be faster and less faulty.

I know that I have probably not found the golden egg in how to do things best yet and maybe it is also sufficient to duplicate a standard local rackspace and do later changes manually.
(I just hate to do manual work :rofl:)

OK - not sure this is a very common use case. That said, I’m not sure why we are preventing the “To GlobalRackspace” plugin from having a plugin handle and we will investigate that to see if there’s a reason it was done that way.

1 Like

Just checking that you were aware that you can copy/paste the global widgets to a local rackspace AND retain the global parameter mapping?
You need to hold Shift key down when you select Paste from the local rackspace panel. This works when you copy from the global rackspace panel (not copy from another local panel).

You are probably right :slight_smile:

But I thank you for taking it into considerations.

Thanks for your input.

Yes - I am aware.
The thing is that since the visual widget layout between the global rack (very much looking like a traditional mixer) and the local racks (small knobs supposed to be hidden as they are only used as “value placeholders”) it does take a lot of formatting to re-arrange the local rack.
I found that it is easier to go then with a standard local rack and duplicate it to create “real” music racks :slight_smile:

1 Like

Well, apparently I’m wrong. As far as I can tell, there’s no reason to special-case that plugin so for the next release, (whenever that is), it will be allowed (unless of course somebody finds a reason why it shouldn’t be allowed before the release :slight_smile: )