Understood (I didn’t mean to sound critical).
Does what Solomon and I are saying make sense to you?
You don’t sound critical 
(I hope I’m not, too).
Just make sure to test, and I’ll index your findings somewhere.
1 Like
This is just up me alley …
I have decided to place common instruments in GLOBAL and create different MIDI IN configs depending on my needs. Then, via each local rackspace, I activate the one I actually need.
If in whichever songs I don’t need any of those sounds in Global, I have a button in LOCAL that deactivates all instruments and FX plugins in GLOBAL.
MY ISSUE … If I change to a rackspace that doesn’t use GLOBAL instruments, the widget is OFF (mute everything in GLOBAL) BUT, it doesn’t actually respect the command UNLESS I press it manually.
It’s as if this widget’s commands were executed first in line and then the previous GLOBAL state were to reactivate itself.
If I change from a rackspace that already had GLOBAL instruments inactive, then all is fine. i.e. the instruments in LOCAL sound on their own with no underlaying GLOBAL sounds.
Any ideas on how to solve this?
Thanks in advance
1 Like
Check if the widget property „ignore variations“ is checked
It was off so I turned it ON but it does the same.
It’s not just between variations. It’s from one rackspace to another …
What I have done is, in a separate panel in global, I created a widget for each variable that I wish to bypass, grouped them to a widget. link and parameter assignment “X”, then In LOCAL, I access that specific Parameter assignment via a widget. It works perfectly if I press it manually, but it doesn’t seem to respect it’s function when iI actually change to a new rackspace
This is my GLOBAL backspace (for now). The squares on the right are where I will be inserting each variable for each song’s particularity. i.e. octave, range, key velocity etc etc.
This is the GLOBAL wiring view.
In some songs (latin America piano) need compression, others need specific EQ or LOWPASS sweeps, etc. etc., So I need to control all this from LOCAL.
another thing is that I am finding is that I will be needing to place THIS panel:
in all my rackspaces and assign each function EACH TIME … CRAZY… there must be a simpler way …
My initial thought was to create a single widget that deactivates all plugins in GLOBAL when I don’t need them and insert this last panel in ONLY the rackspaces that DO need them … BUT I have come across the first issue which is that the BYPASS widget doesn’t work as it should.
I stumbled over the same problem when building my bassamp setup using the global rackspace massively.
The trick is to create your first local rackspace and assign all functions correctly and then use “duplicate selected rackspace” for building the following ones. This way the new rackspace will remember the assignments.
That will be way faster than remapping all the parameters!
I my case I had to map 116 of the possible 128 Global parameter assignments, so another hint:
Switch on “Show parameter numbers in widget parameter selection list” under “options->display”.
This will make mapping much easier if there are a lot of parameters with same name like “wet” “bypass”, etc.
Further I don’t know if it will help solving your problem:
It’s as if this widget’s commands were executed first in line and then the previous GLOBAL state were to reactivate itself.
Make sure that your global parameter assignment to your bypass all/ enable switch is the last possible global parameter assignment (number 127).
When you send changes from your local rackspace to the global rackspace it will send global parameter assignments in numerical order!
So be sure you to handle it like your heart: “a bypass will always be the last thing you need!” 
Hi @DerBecker …
I completely understand the first point you make… And that is exactly what I have been doing since the beginning : 1 template with everything assigned then just duplicate and modify to your needs… The problem is when you have everything up and running and in the future you want to add a new instrument in global and you have to add a bypass button in a local panel … You should be able to add that button to a “master panel” and assign it just once… not have to assign it in EVERY single rackspace. In my case I have to do this so that I can bypass that instrument in rackspaces that don’t use it, otherwise it will sound in songs that it shouldn’t… do you understand?
Lately I added the B3 organ in global because I’m starting to use it quite often. So, I made a panel with the bypass button, the EQ bypass button, a preset selector knob and about 7 other typical functions you can tweak in a B3, so that I can design the sound in local for each song…
I have spent 3 whole days inserting that panel in every rackspace so that I can assign the B3 and B3Eq bypass buttons in every rackspace that doesn’t use the B3 and all the other functions in rackspaces that DO use it … It is just so very annoying not having such a simple functions like Master panel memory or whatever you may wish to call it… You update one panel and WHEREVER that panel is being used, it just updates for all rackspaces… simple… 5 minute job … 3 days!
I will definitely try the solutions you offer and thanks ever so much for the info…
Totally agree with you here!
In a vital system where things dynamically change it’s really annoying.
When I created my actual setup I stumbled over the same problem and decided to build a new gigfile from scratch.
But this could be challenging and time consuming when you have a complex setup with maybe 150 rackspaces.
But often that’s the problem with such flexible Software - as a developer you have to consider all the ways users will work with your product and decide how to deal with things like that.
Maybe it will be possible to save/load a panel with the assignments in the future.
Yes, hopefully!
That would be awesome
You don’t have to move it into the GR. You get the benefit by just having those presets in individual local rackspaces that you can then reuse aming different Song/SongParts as needed in Setlist view. What I do is create Variations within each rackspace, so that let’s say I have a frequently used piano, an organ, and a strings patch in my rackspace. But through Variations (changing the configuration of the related MIDI input blocks, using widgets to set the different values in the different variations), those sounds may have different note ranges, different transpose values, and bypassed or not, in different songs, all using just one instance of each plug-in, in one rackspace (quicker load for the Gig file, and reduced resource usage).
Do, in that rackspace, I’ll create a group of widgets for each sound, actually for each MIDI input block,
mapping those widgets to Min Note, MaxNote, Transpose and Bypass properties of the MIDI block. Then I’ll create a variation for each different configuration I need. The widgeys will of course be there the same in each Variation, but they can hold different values in each one. So now maybe I have three songs, same sounds but in different splits (maybe in one, I want to play organ with my left hand, piano in my right; in another it’s reversed; and in a third I only want organ, no piano). I can achieve all those configurations using just one instance of each plugin, in just one rackspace and it doesn’t have to be the Global
Variations and setlist view used together make a really powerful tool. Hope this is helpful
Yes, this is an option. I definitely do this.
The downside to me is this sometimes requires adding new instruments to rackspaces, along with creating new widgets, etc. So, I get concerned I will inadvertantly do something that will mess up my original rackspace used in another song (and maybe I won’t catch it before a gig).
If you us a MIDI in block in the Local Rackspace (using OSC) and only have the plugin in (e.g., Kontakt with the instrument you want) the Global Rackspace, I there is less change I will mess up a different song. (I hope that makes sense).
Jeff
In my case, I’m very deliberate about what goes in the global rackspace.
First, I connect my audio interface to the To/From Rackspaces block. That way my Rackspaces never connect to the Audio I/O directly.
I always put a limiter before the audio output in the Global Rackspace. It’s set and forget.
I use the MIDI Player on most things. I have the MIDI Player in the Global Rackspace going to a virtual MIDI output. It includes a Widget to select the Song. Each Rackspace has a Knob to select it’s song. I also have buttons for Next/Prev Song/Part and Play. These include MIDI mappings.
Oh yeah, I handle the Lyrics Show/Hide function here too.
If you want something else that always applies, such as a low cut or low shelf filter, possibly controlled remotely via OSC, you could add that here too.
But my overall starting point for most any user would be to map the Audio Input to To Rackspaces. From Rackspaces goes to a Limiter, then to the Audio Output.
To save other, more specific resources, reuse Rackspaces and use variations. As soon as you decide that it doesn’t meet your needs, you can add a new Rackspace and keep using the old one, when it makes sense.
Putting too much into the Global Rackspace misses out on some of the key benefits of Gig Performer. But it’s a great resource for the parts that you want to design once and forget about, but only when it never needs to be touched for that next song or setup.
I think there are two pretty different uses for the Global Rackspace.
I think the original thought process was to use it for effects (especially for guitarists and people using GP for full band productions). (I don’t use it much for this purpose).
But, I think it also serves an important role in ram management for keyboard players and others that use ram heavy sample libraries. If you you re-use a ram heavy “sound” (big piano, horns, etc.) in multiple rackspaces, you conserve by putting it in your Global Rackspace once and then reusing it in local rackspaces as needed through OSC (at least that’s how I do it).
The beauty of this (I am only recently started figuring out) is you can do all midi and audio processing in the local rackspace. So, you can use different splits, effects, layer with different instruments within each Local rackspace without loading additional ram for the instrument itself. This is very flexible and very ram efficient.
(I know there are also other great way to conserve ram that should be considered, but this is a nice one too).
There is another way to conserve RAM, but it’s more advanced - use multiple instances. This has the added benefit of separating CPU usage into different cores.
In my case, I have a main mixer Gig, and it is fed by separate vocal, guitar, bass, keys, and drums gigs. When I go to a song, I might use my standard piano rackspace and P- bass, but a unique guitar setup, with Latin percussion. Any song could have any combination of existing Rackspaces.
It adds some latency to route audio from the “player” gigs to the mixer, but it’s still tight to my ears.
And yeah, it’s complex. But I’ve found it to be reliable.
But yeah, I could see keeping, say, piano and organ always available in the global rackspace, and adding local rackspaces and variations for unique needs as a way to keep things flexible and efficient.
Yep, using multiple instances would definitely seem to allow you to use additional cores. That should help with CPU (and frankly limited ram usually translates to using more CPU).
Ahh, I see how that might allow you to conserve ram. I basically allows you more flexibility in using rackspaces on the difference instances. So, you may be able to avoid duplicating ram intensive instruments. Got it (it took me a bit to understand this point).
(On the other hand, if you duplicate the same ram intensive plugin/sound and different instances, I would think you are using more ram. But, I think your point is to avoid duplicating ram intensive instruments.)
Jeff
Exactly. Let’s say a keyboard player uses piano, organ, and a wide number of synth sounds. One instance could host just a piano. There might be a number of variations, based on splits, whether it’s played by the bottom or top keyboard, etc. A second instance hosts your B3 with variations for various drawbar settings, etc. A third instance could have a ton of rackspaces and variations for a wide variety of synths.
The main Gig selects your songs and Song Parts. The other instances go to the same Song and Song Parts. (This feature is built into Gig Performer.) You can then mix and match the sounds, where they are mapped, etc.
Alternatively, you could put the piano and organ into the Global Rackspace, but it doesn’t support variations, so you wouldn’t be able to have different organ sounds automatically come up on different Songs and Song Parts.
As is typical, for flexibility and powerful features, we get more complexity. The Global Rackspace is simple to use, but it’s more limited. The best solution depends on the use case.
I don’t try to change sounds using variations. But, I think you could have the same control of sounds. You would create a widget in the Global Rackpsace and connect it to your Local Rackspace, where you would set the widget to select the sound you want. (I could be wrong. Like I said, I never do this).
But, I think you only want to use variations to select “sounds” in physically modeled plugins. If you are using a variation to change a ram intensive sound, this increases the likelihood of instability in your system (your system has to load the samples when you change variations, unlike the sounds in rackspaces which are properly pre-loaded).
But, for physically modeled plugins, I don’t even worry about ram. I freely duplicate those in difference rackspaces since they use so little ram.
Whoo, we’re getting into the weeds here. Hah!
Jeff
You can use Variations to choose different sounds without loading and unloading.
Let’s say you use a few sampled pianos, say a concert grand, Rhodes, Wurli, and an upright. Put them in parallel in your rackspace. Add MIDI Processing Blocks before each one. Always pass Note Off, but add four Widgets to independently enable Note On to each sampled instrument. Make a Variation for each instrument, setting the Widgets appropriately. Now, any Song Part can use any of your four pianos. They are always loaded, and never unloaded or reloaded.
In addition, the Rhodes and Wurli might have some modeled controls, like tone, chorus, vibrato, and amp drive. Add more Widgets, and any song can use those sounds too.
Of course, there are ways to do this while keeping the common instruments and Note-On selectors in the Global Rackspace and also placing Note-On selector Widgets in the Local Rackspaces. Publish the Note On properties from the Global Rackspace, and you can control them from the Local Rackspace.
I use this approach for a small number of features that always exist in my Gigs, but that need local control. An example is my “show lyrics” function. It’s in the Global Rackspace, so I don’t have to clone it or remember how it works, but I can enable or disable it, song by song.