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.
- Global effects used by some rackspaces but not others
- Final mixing
- Keeping a few instrument plugins around that are used all the time
- 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.
So, well for, locally controlled, global mixing purposes, I use all 127 global parameters available 
But it works pretty well! 
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.
You are right, but I don’t add them, they are already there, I only use them or not.
My local Rackspaces are still a bit experimental, but I am already really satisfied by my Global Rackspace.
Not sure if I understand fully.
When you create a new song or rackspace, do you create new widgets to sync or bind with the global rackspace?
I’m thinking to have all settings for a saying in a simple long string in a text label, eg
F, 1U: string, 2L: piano
Where f means Hammond speed fast, channel 1 upper keyboard with name string and channel 2 lower keyboard with name piano.
So when new parameters are added i don’t need to add new widgets for each rackspace.
No, I don’t create anything, I start from my rackspace template which has everything in it, I replace the plugins, I modify the label names, that’s it.
Why not, but, I prefer to keep close from GP concepts, e.g. using widgets. The use case I explore could then help to extend GP in the future.
1 Like
But how can you save the mixer settings from the global rackspace in each local rackspace?
As the mixer settings will differ per local rackspace.
You don’t save the mixer settings from the global rackspace in each local rackspace. The local widget are mapped to their global counter part in the global Rackspace. So you save with each local Rackspace the local widget states. When you switch to another local Rackspace, the local widget values are set to the mapped global widget.
1 Like
Ok thanks, now i understand.
This would work when the template is finished, meaning it doesn’t change anymore. In my case i keep changing the template and then i would also change each local rackspace unless i go for some backwards compatibility method
But it opens possibilites to go for this way as well. I need some good thinking.
1 Like
Nice Rackspace!
@David-san … I am inspired by the keyboard… I am assuming its just ‘shapes and text boxes’… but i thought i would at least ask… are they active in any way?.. light up? change colors? play?
I hope you don’t expect me to give you all my secrets? 
Because I won’t 
:
2 Likes
[quote=“[Gig] Illuminated Piano, post:1, topic:6412”]
This gig file uses a Scriptlet which illuminates played keys on a piano.
[/quote]
Woww! 
1 Like
This is exactly what I have been trying to do, and I ended up using OSC to set the plugin names in the global rackspace from the local rackspaces script. Your solution sounds better. How did you share string values between the local and the global rackspace?
Solomon
1 Like
My solution is not better, it is only that I didn’t want to add some extra GPScript in each local racspace for this. So everything is done from the global Rackspace GPScript.
I do something like that in the global Rackspace GPScript:
For i=0 ; i<16 ; i=i+1
Do
If BindExternalWidget(local_VST_WIDGET, "VST_LABEL_"+(IntToString(i+1)), GetRackspaceNameAtIndex(GetCurrentRackspaceIndex()))
Then
label = GetExternalWidgetLabel(local_VST_WIDGET);
SetWidgetLabel(VST_LABEL[i], label);
Else
SetWidgetLabel(VST_LABEL[i], "default name");
End
End
With this kind of mechanism, if you have an older local rackspace which doesn’t follow the new organisation (a set of label widget with handle names VST_LABEL_1, VST_LABEL_2…), then you can default the global label widget to what you want.
1 Like
Ah, brilliant. Well, in fact, I disagree: yours is better, precisely for the reason you say, i.e. I don’t want to have to put GPScript code in every local rackspace for that; for one thing, it’s hard to maintain (did you see my previous topic about my attempts to do a global regexp search-and-replace across all rackspace scripts?), and for another thing, hiding important rackspace data inside scripts rather than placing such data in widgets is obfuscating).
Also your solution manages to get around the 128-parameter limit for global parameters! I love it.
3 Likes
I am happy to see you happy 