Rackpanel alias

The Global rackspace is really awesome!

It would be AWESOME if there is a function to automatically alias the rack panel of the global rackspace (widgets) to the individual rackspace (assigned to global rackspace automatically), so you don’t have to (create and) assign the widgets in each rackspace. Especially when you want to add a widget in the global rackspace and you have made already 40 rackspaces. Now I have to add 40 times the same widget.

Is this a possibility (and hopefully easy to create)?

PS: I know I can duplicate the rackspace, but If you already have a gigfile with a lot of rackspace with complicated rack panels, the editing is a lot of work. And each change is times 40

1 Like

I second this request. Maybe not only widgets on panels, but also modules in wiring view of a rackspace.

Could be a right-click option: “Copy to all rackspaces” “Sure?” Go!

I hope the guys can come up with some sort of alias. With copy it is at some moment a copy, but It would be great if every change is automatically updated in the rackspace

Hmmm no response. Not used to in this forum.
Still curious if this feature request is a serious option.

I really don’t like the idea of automatically aliasing or referencing.
That could lead to unwanted effects when using scripting.
But that is only my thought.

What to do when you explicitly do not want an referenced widget?

I have the feeling that with such a possibility many issues could be introduced coming from the back Stage.

Just a thought:
If you alias all the widgets automatically in the rackspace, all the widgets should read the last value. By selecting a widget in the normal rackspace and change the value it should only change that parameter.

We always appreciate new requests coming in to add to our ever growing existing list. We have a huge list of features to consider, from customers, from our beta group, from ourselves, etc. — but sometimes there’s just nothing to actually say about a particular request.

1 Like

Why can’t you just leave the global rackspace window open? Why is it necessary to alias every widget in the first place?

Can you adjust the global rackspace in the setlist mode and save the values?

Not right now - nor am I sure one ought to be able to do that. The whole point of the global rackspace is that it is, well, global – you set stuff there that for the most part you don’t want to be dependent on individual songs…e.g. global EQ, a phaser effect that you might turn on/off from a keyboard or pedal, etc.

What exactly are you trying to accomplish?

I use the global rackspace for two layered instrument. (Strings and organ).

I made a rackpanel for the organ and strings (drawbar etc)
I’d like (in a normal rackspace) save the drawbar values in the song.

Why not load presets:

The idea is to save user presets from the plugin.
This user presets can be loaded via scripting.

And this is the script used in the global rackspace

   BLUE3 : PluginBlock
   LPR : Widget

// Called when a single widget value has changed
On WidgetValueChanged(newValue : double) from LPR
 if newValue == 1.0 then
  LoadGPPreset( BLUE3, "Preset1")
 if newValue >= 0.4 and newValue<= 0.6 then
  LoadGPPreset( BLUE3, "Preset2")


Just take a look at this gig
LoadPreset.gig (143.7 KB)

The trick now is to link the local widget with the global widget and when you switch variations the desired preset is loaded.
No need for tons of widgets controlling plugin parameters.

This is just a quick & dirty proof of concept.
With scriptlets and parameters it would be even more elegant code.

1 Like

I like @pianopaul’s solution a lot, but with the caveat that the GP 4 script documentation still says:

LoadGPPreset(*p: Block*, *presetName: String* ) Autotype
      Load a GP plugin preset in the background - seriously experimental and probably very unsafe

I’ve gone back and forth about how much stuff I stick in the Global Rackspace and manipulate through presets, linked widgets, or other sorts of tricks.

I’m enthusiastic about this kind of “LoadGPPreset” but not yet sure if I should rely on it not changing.

Indeed — it’s still unclear how safe that mechanism is — if a plugin is buggy, this could cause a lot of grief. Hence it’s still experimental until we can get more feedback from users who have plugins that we don’t have.

In the short term, the workaround that might save some work is to create a separate panel with the desired knobs on it – export that to file, then import it into each rackspace and connect the widgets to the global widgets — not an idea solution but better than repeating the entire layout for every rackspace.

1 Like

Not a fan of creating a new preset for every little change. For me, that’s were the widgets are for.

I understand the rackpanel export / import and assigning the widgets. That’s why I thought of working with aliases. Because I imported the rackpanel in every rackspace, and then had to add 1 widget in the global rackspace. I then had to change/add that widget in every rackspace.

I hoped I could use the rackspaces for the seperate sounds and use global rackspace for the organ. The advantage of the global rackspace is that I don’t have to change this in every rackspace. Now I could copy the organ plugin in every rackspace instead of the global rackspace.

Just another thought:
When you copy the widgets from the global rackspace and past it into the local rackspace maybe it would be handy to assign the pasted widgets to the widgets of the global rackspace.

This would not be an complete automated aliasing but it could save work.

I think this issue is independent of the Global Rackspace. e.g., before there was a global rackspace I still had to copy or import a B3 drawbar panel into every Rackspace where I wanted a B3 drawbar panel. And then if I changed something it’s quite cumbersome to make that change to every rackspace.

I do like the concept of having some sort of “master” version of a panel that any number of rackspaces can reference. Whether that’s in the Global Rackspace or somewhere else is kind of a separate issue. I don’t want B3 in my Global Rackspace, but I’d sure like to have one master version the others all follow.

Like this one?
2nd rackspace
LoadPreset.gig (258.4 KB)

I like and use that feature of linking “local” widgets to the Global Rackspace, but the more different places you try to do it the more complicated it gets.

For example, these are rackpanels I made for the Lost in the 70’s plugins to demonstrate an external API control surface extension. The colored shading for the two fader banks indicates which one the MCU controller is currently “attached” to. Same for the knob banks. So you can touch a button on the controller to “bank switch” what you’re controlling and the shading follows it.

The more complicated these get, the more of a pain it is to update them everywhere. Especially if it’s just “artistic” stuff like sizes, colors, labels, etc.

I add this to the discussion because in my mind it’s complicated to figure out what’s the “right” approach to managing the “alias” stuff @Keyflow is requesting (which I think is still “Rackpanel aliases” and we’re in the “Feature request” section.)

I think it would be awesome if I could have a “Master B3 Panel” that would automatically update in every Rackspace I placed it into, and I wouldn’t have to rebuild all the widget links to the VSTs like I do with the “save/import” approach.

It’s just not yet clear to me what the best way to manage something like that is, especially when considering the underlying VST might be in the global rackspace (as Keyflow is thinking) or might be in each individual Rackspace.

1 Like

One “simple” option of having multiple organ presets within the Global rackspace is the HaNonB70 plugin included in GP4. Within the plugin are 10 preset buttons easily assigned to widgets. Not the ultimate B3 but decent enough for a lot of situations.
HaNonB70 Global.gig (392.3 KB)

EDIT: However, these settings wouldn’t be savable to songs. :thinking:
EDIT 2: I figured it out.