Global Rackspace Snapshot?

ah! I just moved my 8 chan mixer etc over to the Global Rackspace, and… expected the snapshot to save the mixer settings, but alas… it doesn’t appear to do that.

Any suggestions on how to save those mixer settings (in the global rackspace) on a per rackspace or per song/part level?

thanks, Eric

1 Like

You would need to replicate the widgets in each local rackspace and use the ‘global parameter assignment’ options in the widget settings, as described here:

3 Likes

ah! thanks! I will test that out this morn

1 Like

Gonna mark this solved. Thanks

Ouch… This makes me think my template rackspace will not work in a global rackspace.

Copying all Widgets in each rackspace is exactly what I want to prevent.

Maybe I should create my own serialization solution.

Would a feature request to store global widgets per rackspace be feasible (without the need to copy them to the specific rackspace)?

If you have a local Rackspace template ready with these widget in it, you don’t need to copy them each time. That’s exactly what I do.

@David-san

I’m afraid i don’t understand you fully.

Is there something like a rackspace template in GP? Like a rackspace that well be automatically placed inside each rackspace and where the widgets can be accessed from the global rackspace script?

Btw, I also don’t want to change all my existing rackspaces when I want to make a change in my ‘template’ rackspace.

And when I want to change that rackspace (template) I only have to change it in one place?

No such thing at this point. The notion of a “live” template has been suggested before but it’s not at all obvious whether this is a good idea. I’m not sure people want rackspaces changing by mistake.

1 Like

@dhj

Thanks for the confirmation.

I think I will than make my own serialization solution, might be a challenge.

Some algorithm like this:

  • when a specific (save) button is pressed:
    • assemble the values from the global rackspace (and local rackspace) in a single string
    • save this to a file with the local rackspace name

And for a load, do the opposite.

I think this should be possible.

But it would be nice if the global rackspace values would be stored with a local rackspace snapshot. Or if there would be an option for this.

Have you considered using Gig Performer to actually make music? :slight_smile:

2 Likes

LOL I do already and I like it a lot.

Global rackspace values are, uh, global. Rackspace switching is intended to be instantaneous so you can do it in the middle of a beat. The last thing you want to do is have to set maybe hundreds of extra parameters every time you switch rackspaces.

It really seems like you’re trying to push GP to be something for which it was not designed.

Another easier solution could be to combine the values of all global rackspace widgets to be stored as a snapshot per rackspace, sync them to a local rackspace widget and use the default snapshot feature of GP.

Sorry for being a nuisance sometimes.

Maybe it’s best if I contact you later when I have my laptop nearby to explain what I would like, or what I like to accomplish.

You’re not being a nuisance — and ideas and suggestions are always welcomed. But context is important. For the majority of users, the purpose of the global rackspace is to do, well, global things, e.g.

  1. Global effects used by some rackspaces but not others
  2. Final mixing
  3. Keeping a few instrument plugins around that are used all the time
  4. Initial processing for guitarists before using rackspaces for individual effects

It is intended to be controllable from individual rackspaces where necessary (e.g, a rackspace that uses a global flanger might have a widget on it to control the global flanger speed or depth) but it is not intended to be part of a rackspace.

2 Likes

Thanks for the explanation.

And I understand the idea of the global rackspace.

I’m going to think about how I still can accomplish what I like and I’m already knowing that GP is flexible enough to make it feasible, whit some or a bit more scripting.

No, I have my own template with all the widgets I need all the time for mixing/activating the different plugins. The plugin mixer takes place in the Global Rackspace, but it is localy controlled by my local template (which is adapted for the particular needs of each songs). The Global GPScript looks into the local Rackspace and retrieves missing infos like the plugin names which are displayed in the Global Rackspace. A widget based representation of my motorized control surface is also in the Global Rackspace and it syncs everything with the hardware control surface. When the Global Rackspace doesn’t find the widgets of my newer local template, then it defaults to have no impact on my older Rackspaces.

In the following animated GIF I go through different local Rackspaces/Variations and you can see how the Global Rackspace adapts (and you cannot see it, but my morotized control surface and its display adapts accordingly). The first rackspace (Goodbye Stanger) is an older rackspace and as exected the Global Rackspace doesn’t find the appropriate widget structure and defaults eth Global Mixer settings such that it works seamlessly.

My_Gig

So, well for, locally controlled, global mixing purposes, I use all 127 global parameters available :grimacing: But it works pretty well! :innocent:

2 Likes

Are you complaining you’re using too many parameters or are you looking for more than 127 parameters?

I am not complaining, but I exactly reached the limit of 127 which is enough for my current need. But I could not add one single widget more… Increasing to 256 would give me chances to add more widget if needed in the future, but for the moment it is OK. I don’t know If I rather should use GPScript to retrieve the state of the local widgets, but I preferred using the built-in options for the moment.

1 Like

@David-san that’s a very cool panel, not as nice as mine but eventually I might want something similar, except I don’t want to add a bunch of widgets on my local rackspaces. That’s probably how you save the mixer settings via snapshots?

I will check this post again for future ideas.