Recently began testing Gig Performer as a possible replacement for NI’s KORE 2 in my live setup and despite some realignment of thinking required, so far I like what I’m seeing. One of the things that kept me using KORE (6 years discontinued and unsupported) was its ability to store any variations in an instance’s instrument and plug-in parameter states on a per patch basis. MainStage’s patch aliases only allow a few basic parameters to be changed per patch. With variations, Gig Performer accomplishes the same level of flexibility, which is great. However KORE also allowed me to set on/bypass states for any instances in a concert per patch, letting me say split a piano instance with an organ one, or layer strings onto the piano with a MIDI CC control.
Haven’t found a way to accomplish this in GP by using variations. If I desire splits or layers of other instruments on a particular piano variation, must I make that variation its own rackspace to add instruments not needed in other piano variations? If so, how does having multiple rackspaces containing the same instrument and plug-in chain impact GP’s CPU and memory footprint?
Thanks for any advice you can offer and for creating what looks to be a very interesting contender for a live performance solution.
I use many instances of Omisphere in different rackspaces.
With predictive load enabled this is very smooth.
CPU and memory usage is very low compared to mainstage.
In mainstage I used alias channels and multimode, very complicated.
Back from Ableton Live I show the current Scene in GigPerformer together with tempo display and Song Position, all done with OSC.
With Mainstage I had to use 128 Samples Buffer, in GigPerformer I can use 64 Samples and the CPU Load is much lower than in mainstage.
Check out predictive load, you will be happy.
But be aware that switching through different rackspaces within seconds is technically not possible, David described this mode very well in a Blog.
I use that mode live and it is working like expected.
I often have a bunch of instruments in a single rackspace but I’m only using some of them at any time so I just use variations to turn on/off what I need at any particular time. Really depends on what plugins you’re using.
But sometimes it makes sense to use multiple rackspaces so you can leverage Patch Persist as well.
Sometimes it even makes sense to use a separate Gig Performer instance for some instruments. For example, many people might create a separate GP instance just to hold a single hammond organ plugin which they control from one keyboard and it’s just there all the time. In that case, you have less plugins per rackspace in your main GP instance so it’s easier to manage them in a single rackspace.
This restriction is only when you’re using predictive loading and you try to jump to a random rackspace that’s outside the range that gets preloaded as you move through your setlist. You’re trading off the ability to manage a much larger collection of plugins against the ability to jump completely randomly from one rackspace to another.
Predictive loading is aimed at users with a predefined set list when you know the order in which you’re going to play your songs.
But be aware that switching through different rackspaces within seconds is technically not possible
Thanks for your input, David. My style is to keep items in more or less the order of a set for easy access, so it sounds like predictive loading would be great. I love that rackspaces can easily be reordered when the set list changes.
Regarding something like Kontakt, my MO has been to use as few instances as possible, create instrument banks for each instance, populate it with the patches I wanted and use MIDI program changes to call up the appropriate patches per song. Is this method still feasible, or would it be just as economical to put a Kontakt instance or two loaded with only the instruments needed for that song into each rackspace? From what I’m understanding, it sounds like predictive loading might favor the latter.
unless you actually have memory issues - you really don’t need predictive loading. You can certainly try it both ways. It’s - just an option after all, but unless you are running out of memory - it is better not to use predictive loading.
Personally - I like to have everything in different rackspaces and use variations just for variations on the same sound. If I want to switch between sounds/instruments completely - I would use a different rackspace rather than trying to create variations with bypasses. It is smoother to use variations and, as David mentioned, you can use patch persist feature.
Btw… As far as splitting goes - you can create splits using the key ranges or even velocity ranges. You simply create one MIDI IN block for that keyboard, select the key range for example and connect it to your instrument. Then you create another MIDI IN block for the SAME keyboard and select a different key range, connect to a different instrument and so on.
Kontakt does its own streaming from disk. I use a ton of Kontakt instances in my live setup and I don’t use predictive loading. However, I often use the purge trick to reduce the number of samples that actually have to be loaded. That’s less for RAM concerns but really just because you can load everything faster. It does help with RAM concerns as well though. See my blog article on this topic at /how-to-save-a-ton-of-memory-if-youre-using-kontakt
The instrument bank feature in Kontakt does work but you need to make sure you use program change numbers that are NOT associated with Gig Performer rackspace variations otherwise they won’t get passed through.
Yet another approach, if your keyboard supports it, is to use a Multi and associate each instrument with a different MIDI channel. Then you can quickly switch from one sound to another by changing midi channels. I have several Roland A800s for example and they have a knob that makes this very easy. HOWEVER, you need to be careful not to change MIDI channel while a note is still being held down otherwise it will get stuck.
Separate rackspaces and optionally Patch Persist is generally a better way to go but your mileage may differ, hence there are several ways to skin the cat, so to speak.
Thank you Nebojsa and David, I’ll try it with and without predictive loading to see what works better. Nebojsa, your suggestion of when and when not to use variations follows my newly informed inclination of using separate rackspaces for most songs. David, I’d already read your blog on streamlining Kontakt for Gig Performer and am implementing that. Great suggestion! I’ve used Multis before, but ended up using Kontakt instrument banks over Multis after running some stress tests with MainStage a couple years back and finding that banks loaded a little faster and didn’t use additional memory if the same instrument sample set was contained in multiple patches within the bank. Already using the multiple MIDI in blocks to accomplish splits and layers (very intuitive once grasped) and wishing there were a ‘Learn’ button for setting MIN and MAX notes. So far, this is really a wonderful app to work in and am looking forward to integrating it into my live rig soon.