I have created rackspaces for my main sounds (Piano, Rhodes, Wurli, Hammond, Brass, Strings, Vibraphone, Trombone, … with widgets to control the parameters (transpose, key range, sound parameters (e.g. hammond drawbars, percussion, vibrato, … Rhodes with all effects…). If I would like to create a rackspace now with Piano, Hammond and Brass split accross the keyboard in one rackspace is there a way to cut and past the existing rackspaces and wiring diagrams and maintain all the widget allocations to the controls.
This has come up before. I think the answer is “no”. (Of course, you can duplicate the rackspace to start from there, use the Global Rackspace, etc., but that is not really your question).
This means I have to keep re-doing the same work again and again, as soon as I want to integrate e.g. my complex Hammond rackspace into another one. I can cut & paste rack and wiring however I always have to reconnect the widgets. It would be nice if Gig Performer was supporting hierarchical design (e.g. like you have in software or hardware design), where you build up more complex structures by reusing the simpler ones.
The design of Gig Performer does no follow a hierarchical pattern and I think the developers have a good reason why it is implemented this way.
Do you have created separate rackspaces for Piano, Rhodes etc?
And now you want combine some of them in a single rackspace?
You could export as favorites and import.
He’s wanting the widget mappings to be maintained also. That can only be done with importing entire rackspaces.
But when He wants combine separate rackspaces to a new consolidated one,
then import does not really completely.
Right, there is no way to merge rackspaces.
What is this good reason ?
I am a normal user, so I cannot say.
would this maintain the widget allocation from the panel to the plugins ? At the moment I have saved all rackspaces and can import them that is fine. However the import does not support importing them into a larger rackspace.
Favorites do not save widgets and mappings
Thanks all for your replies.
I think I have an idea now how to do it. I will create one large AllRackSpaces rackspace with all my rackspaces inside. Any new rackspace I develop I will put into this AllRackSpaces rackspace. Then In the end I can create any new rackspaces (combination of the basic rackspaces) from this by deleting the ones I dont need. In this case the allocation of widgets from the panels to the plugins in the wiring should be maintained.
This means I can keep current panel design and wiring for each of my basic rackspaces which I will put in the AllRackSpaces rackspace, however I have to reconnect the widgets to the plugins again, but only once.
I’m not sure what you mean by putting all your rackspaces inside another (AllRackSpaces) rackspace, as that cannot be done. Maybe you mean something like a master gig file??? When I want something more or less similar with some changes, I usually just duplicate the RS (or import one) and make my edits to that.
I did it yesterday night. It works. Took some time. Now I have one rackspace (AllRackSpaces) where i included all my basic rackspaces (panels and wiring). I re-connected all widgets from these panels to the corresponding plugins in the wiring. Now if i want any subset of my basic rackspaces in a single rackspace I import the AllRackSpaces rackspace and delete the panels and writings which are not needed. The connections of widget on the remaining panels to the corresponding plugins for the remaining plugins is maintained. Therefore I no longer need to redo all the reallocation of widgets to plugins every time i want to reuse one of my basic, but complex, rackspaces (like Hammond, Rhodes, Strings, Brass …)
The “subtractive” approach will surely work as intended, since the maximum configuration/settings are already established and removing parts of it won’t affect the remaining dependencies.
The other way around - merging multiple rackspaces into one - is much more complicated because the application won’t be able to “know” or “guess” what you intend to have as a final result…
Each of the rackspaces will most probably bring its own audio in or midi in, which will result in multiple instances when mergeing rackspaces, but i.e. of audio in’s will only be one available… which one to use, which one to discard?
Each rackspace brings its own panels with widgets and ther corresponding settings, so let’s just assume you would merge two rackspaces with their own widget radio groups (each is group “A”)… what should be done? Change one group to “B”? What if ther already is another group “B” on either of the rackspaces?
What if the rackspace contains scripts… what to do with the respecting widget handle names, with the variable definitions, with potential user functions which might have the same name but do diffrent things in the diffrent source rackspaces…
What if, what if, what if… there will be endless undefined possibillities where each one could cause more or less severe issues.
Merging such “open” subsystems is definitively no simple task to do, and i can absolutely understand if the devs might not be too enthusiastic about implementing such a mechanism.
It would be cool if… but i don’t believe it will happen too soon.
There has already been a lot of talk back and forth about how this would not work, but I have done something close to what you want to do. If I misunderstood your use case this still might help others.
You cannot merge rackspaces, but you CAN save and import/export individual panels from a rackspace. I have 8 VST synths that I use regularly on the global rackspace (Piano, Electric Piano, Organ, Strings, OB-X Pro III x 2, Mellotron, and Stylophone). I created a panel for each one in the global rackspace, setup the widgets, assigned important parameters to global parameters, then saved the panel. I also have a panel that bypasses the VSTs I’m not using in a rackspace.
When I setup a new song I load the panel for the VSTs I use in the local rackspace (I have two keyboards on stage - top and bottom on one keyboard stand), and then setup the parameters I need the VSTs for that song and save them so they load for that song when you switch to the local rackspace. I do have to redo the wiring for each song, but most of the work with the widgets is already done. My VST bypass panel is then loaded and I do the same thing: set the two VSTs I need at the beginning (the widget buttons for the active ones light up so I can see at a glance), and save the parameters to the local rackspace.
In the global rackspace I use a MIDI rechannelizer to send to the individual VSTs, and on the local rack space I rechannel the outgoing keyboards to match the channel of the VSTs on the global rackspace before sending the midi signal to the global rackspace. It works very well.
To save/load a panel you have to be in the rackspace edit mode and right click on a panel. Save is obvious, but to load one you have to go to ‘add new panel’ then load panel.
So instead of ‘merging’ a rackspace, panels you use frequently can be saved and loaded with widgets in a modular fashion so you don’t have to reinvent the wheel each time you create a new rackspace for a new song using the same VSTs.
And this does not need to be a global → local rackspace. You can save panels for global or local and load them as you need them.
I hope this helps you out!
Ah, ok, that’s different. You are not literally taking another RS and adding it to another, but you are just taking the panels and widgets mapping into that main RS. Sure, that’s possible.
He simply created a huge “Über-rackspace” which contains each favourite plugin including wiring and panel design and widget assignment, and then he deletes everything that isn’t used for a smaller rackspace design… so everything still works as it was previously set up.
This is absolutely a viable solution which saves a lot of work and time!