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 