Hello,
I am building a GP set for live performance, using a wide range of synth sounds from different VST instruments and sampled sources. I have already figured out how to automate songs and song sections, using both Ableton Live with backing tracks, and a hardware controller.
I am now about to start building the actual gig performer file with all the instruments, which will require a significant amount of work. However, before investing all that time, I would like to hear the opinions of experienced users to avoid possible disappointment later on.
The simplest way in my opinion is to use
one rackspace per synth preset (as most synth vsts cannot link preset change to widget)
one rackspace with a kontakt bank which contains kontakt instruments which can be switched with pc message from a widget accepting iac driver input
This would lead to the situation that the gig set would contain eg 30ish rackspaces, and 30ish kontakt instruments in the kontakt bank.
Furthermore there would be:
midi in from iac driver for automation of rackspace and rackspace variation selection in the gp setlist, coming from ableton live
midi in from octapad electronic drum pads playing drum sampler vst in gp
all this routed via various vst effects to 3 stereo outs: bass, drms and instruments
Optionally there could be:
2 effect chains with audio fx for 2 singers (audio in from the audio interface). But this could also be integrated in audio interface effect chain (uad appollo console)
As I am new to gp, my question is: will gp be able to manage all this without cpu or ram overload? While ableton Live is playing alongside with backing tracks?
As I watch tutorials and read about how GP works, this approach seems perfectly normal, and GP appears to be specifically designed for this kind of workflow. Laptop used is macbook pro 2,9 GHz Quad-Core Intel Core i7 16 GB 2133 MHz LPDDR3.
In GP only one rackspace is active at a time so you would not be able to use more than one synth or a synth and Kontakt at the same time. There is a “Global” rackspace that is always active (so technically there are two rackspaces at the same time).
People like me that prefer to have sounds that are designed around a song usually opt for one rackspace per song. Others that have a range of instruments they use across all songs generally make rackspaces that cover the sounds they like to play together (i.e. a piano and an organ split across the keyboard). And for the instrument you use basically every song you can put in the Global rackspace. The Global rackspace also can hold eq and mixers that fine tune your setup.
Best practice in modern GP is to route your inputs from the Global to local rackspaces and from local back to Global. This gives a central place for all your inputs/outputs so if something changes (like your audio interface) you’re not updating dozens of rackspaces.
Also, get familiar with Rig Manager if you use multiple controllers or backline equipment. It will be a lifesaver and saves a lot of headaches!
Thank you for the good advice. I will kep in mind the global rackspace in/out and the rig manager. So you are also confirming that 30 vst instrument instances (+ 1 kontakt instance with 30 instruments in 1 soundbank) is theoretically no problem for gp to manage in terms of ram and cpu?
Performance efficiency depends heavily on both the plugins you choose and how you organize them within rackspaces Finding the right balance is key:
One instrument per rackspace is impractical for most performances. Unless you’re playing only a single instrument throughout an entire song or set, you’ll waste time constantly switching rackspaces and may encounter audio dropouts or loading delays between changes.
All instruments in one rackspace is equally inefficient. Loading every sound you might need keeps unnecessary plugins active in memory, consuming CPU resources and potentially causing performance issues or latency problems when you need your system to respond instantly.
The optimal approach typically involves grouping instruments logically—perhaps by song or by section of your setlist—balancing quick access with system efficiency to ensure smooth, reliable performance when it matters most.
Do I understand it correctly that only the currently active rackspace gets loaded into memory - so that is why 1 rackspace per song is the way to go? (And the few things that get shared between songs on the global.)
What rackspaces are loaded Into memory is determined by the option setting for predictive load.
When. predictive load is disabled all rackspaces in the gig are loaded into memory.
Details about predictive loading are documented in the user guide.
One has to distinguish between RAM usage and CPU load… both might spoil the overall GP-experience if driven to high!
The RAM-usage depends on the number of rackspaces loaded at a time.
That’s where predictive loading will help - especially if you use many sample based plugins!
The CPU-load depends on the currently active plugins, which only reside in the active local rackspace and the global rackspace, which is always active. All the other local rackspaces, which are not active won’t consume CPU-power (as well as bypassed plugins).
In case you use patch persist (to create smooth transitions between rackspaces), there is a chance that two local rackspaces can be active at a time (just as long as the transition time lasts), which might produce higher CPU-peaks that might stall your system.
Predictive loading won’t help you to improve such a situation!
My approach is this: I have one rackspace per song. Non-sample-based sounds (= synth sounds), which require little memory, are located directly in the respective song’s rackspace. Sample-based Kontakt sounds that I use in multiple songs (approximately 20 sounds, piano, strings, brass, etc.) are in the global rackspace and are controlled via OSC MIDI from the song’s rackspace. This keeps the gig file from becoming too large and also optimizes the loading time when starting Gigperformer.