Multi-timbral plug ins

Hey everyone,

potential GP3 customer here needing a bit of insight:

Is it true that each rack space uses one fresh instantiation of, e.g., Kontakt 5 (which I use multi-timbrally)?

I have all my sounds in one set on 8 channels with in one single instantiation of K5.
(In MainStage I was able to address any instrument on any channel - in any split/layer configuration.)

I like the feel and speed of GP3 but I can’t figure out how to not have to create so many instantiations of Kontakt (one per Rackspace) in order to get my show needs met.
Variations don’t cover the extensive differences between songs that I need to cover.

Can you please help?
Thanks so much

Sure you can use Kontakt like you did in MainStage.
Every Instrument loaded in Kontakt reacts on its own channel, right?

In this example a Midi Keyboard sends on Channel 1 and in each midi in block you can define the channel which sends to Kontakt.
This way you can implement very easy key splits and each split sends on its own channel to Kontakt.

Do you get the idea?

This should be very helpful:

Kontakt Multi program change

Yes, it is :+1:t2:

Why is that a problem? :smiley:

I think Groovacious believes he has to create a separate rackspace for each sound he uses in Kontakt.

That‘s not the impression I get from his post :man_shrugging:t3:
But if that‘s the case, the assumption would be false.

So to be clear: You can have as many instances of Kontakt (or any other plugin) in a rackspace, you can patch it up however you like (and for instance use a single instance multi-timbrally) but every instance of a plugin is bound to a single rackspace.

Very new user. I’ve got a similar situation where I use HALion and Omnisphere mainly. HALion runs multi-timbrally with 16 instruments and Omnisphere runs 8 per instance. I’m wondering if it’s still the case in GP3 that each Rackspace requires a separate instance of an instrument. In this case, where I currently use three instances of HALion, I would now need to run 48 instances in Gig Performer (!). This would change my approach from using Program Change information to switch Rackspaces to my current method of changing MIDI Channels to access different patches within the same instrument instance. I would use a single, very large Rackspace for my entire show with three instances of HALion loaded rather than 48 separate Rackspaces, each with its own instance of HALion. I read in the forum of a possible Global Instrument, is that in GP3? Or is there a better way to think about my problem?

I am using GP and omnisphere.
With the option patch persist the amount of used ram by plugins can be reduced a lot.
When you use this option you can define a window how many rackspaces should be loaded into memory.
For example 5 means the actual rackspace plus 2 preceding plus 2 following rackspace are loaded. So you can switch between this rackspaces withiut any glitch.
When you switch to another rackspace the window is moved and as soon as the red bar with the word preceding appears you can play the actual rackspace, the others are loaded in background.
With this option the number of used omnisphere instances does not really matter.

1 Like

Thank you. I’ll give this a try, but I get the feeling I may need to adjust my approach to using a single Rackspace rather than one per song because of how my shows work out. There’s no way to know which song is next, so I don’t know how many Rackspaces to preload with Patch Persist. Song/Rackspace 7 then song 34, back to 8. I’ll check to see how well it works with separate HALions per Rackspace. I might start off with my tried and true method of switching sounds by changing MIDI channels within a single Rackspace. But will definitely test both approaches.

I don’t understand, I thought you were used to switch your keyboard setup using the 16 MIDI channels. This would make at most 16 rackspace ? Even if you do it for 3 different keyboards, this would make 48 rackspaces, or eventually 3 GP instances of 16 rackspaces each.

Am I wrong ?

You’re probably right, I’m still trying to understand how I would do this in GP. Yes, I currently have 3 keyboards with 16 channels (48 variations with several patches being used several times: piano with strings, piano with voices, etc). My instruments are 2 HALion instances filled with 16 patches each. Omnisphere with up to 8 patches. Several other synths that are not multi-timbral (Artuia Collection, Korg Collection, and others). I have about 100 channels in Ableton Live that each correspond to a layer. For example, I would layer a piano in HALion with a string patch in Omnisphere. This takes a couple of channels both set to the same contoller MIDI channel.

My question really is: If I have 48 Rackspaces, where each of them requires some layer in a HALion instance, does this mean I must have 48 instances of HALion (one per Rackspace)? It sounds from your comment that the answer is “No, only 3.” If so, how do I set up my Rackspaces so they share these multi-timbral instruments?

Am I asking the question clearly?

I would do so. But, it I feel like something’s bothering you in there. Trust GP’s internal optimizations, prepare your rackspaces and load them all into memory. I’m betting you’re in for a good surprise. :wink:

1 Like

I’ll give it a try (and you’re right—I can’t even imagine loading 48 instances of HALion at the “same time”. Thanks for your help!

I’m planning to load instances of my multi-timbral instruments, but only load one sound per instance, per Rackspace and will report back here.

1 Like

I copied HALion with a single instrument loaded to 35 Rackspaces. It took a little while to load, but wow, it looks like this is the way to go. I think I figured out another issue that I may run into on stage–needing to change the sound on one of my three keyboards to an ad-hoc patch. I’m thinking of loading two or three sounds per HALion instance, per Rackspace, per song. When I need to change my sound (solo patch, etc), I can use that controller’s midi channel (vs Program Change) to call up a second or third sound. I’m pretty excited to get my rig updated with Gig Performer. Lot’s of work to ensure I’m good to go.

1 Like