So I’m making the move down to 1 88 key controller and GP. I previously had 2 61s.
Now I’m going to need multiple “scenes” so to speak for many of my songs. Simple example would be piano across the keyboard and then quickly switch to organ across the bottom of the keyboard with a synth lead up top . In the past I have done a combination of three different methods.
The first is the normal switching rack spaces as I move to each song part. The others are to have all the sounds I need on one Rackspace and just simply enable them or disable them. That can be done either with variations assigned to separate song parts (2nd method) or simply with buttons that enable/disable (bypass) various plugins all within one songpart (3rd method).
The first method leaves me with cleaner rack spaces. The second and third methods leave me with fewer rack spaces. And in particular the last, for some reason, seems safest to me although I have no empirical evidence or real reason for thinking that lol.
The proper way is the one which works for you. Your method #1 makes it possible to easily and seamlessly use the Patch Persist option of GP and you won’t have to think of stuck notes. If you need something like Patch Persist through the variations, you will need to take care of what you are doing to avoid stuck notes or go for this: [Gig] Plugin Persist 2.0 . I think solution #1 is easier.
I always change song parts. Sometimes the new song part will point to an entirely different rackspace. Sometimes I will use a variation of the same rackspace.
To me the chief benefit of using a variations instead of a new rackspace is you are not loading the same instrument into ram multiple times, which I sort of feel “wastes” ram resources.
But, you may be switching to something that you already have a perfect rackspace for (that you use in other songs). So, might as well use that.
I think we’ll always see this issue a bit differently, David.
I like to always have all my rackspaces/songs loaded in my big main (only?) Gig file. And, I like sampled instruments. So, duplicating the same instrument in multiple rackspaces would seem to use up ram for no good reason.
Since I like one huge gig file with everything, over time, as I add more sample libraries and rackspaces, it will continue to require more ram.
But, true, moving to the Lenovo (64 GB ram installed, with an option to max out at 128GB) I should be in good shape for the long haul.
For what it’s worth. I used to have one rackspace per song. Resulted in a much larger loading file and in setlist mode would be more problematic unless you loaded all your rackspaces into memory.
I moved to songs that reference the same rackspaces which reduced my file size and loading time.
Downside was that my audio player which had a copy of the song for practice purposes per rackspace was no longer valid but the Streaming Audio File Player has solved this.
So at this point I’m a fan of the multiple songs per rackspace (Also beneficial if you find you need to change settings for that sound) . One change to the rackspace covers all the songs it references.
I think that a deciding factor is whether you have “your sound”, or if you’re doing covers that you want to sound just like the album. Weird Al’s band would probably use a different rackspace per song.
In your example of adding organ, I accomplish a similar task by using multiple midi input blocks within a gigperformer rackspace, Then I switch them in and out as needed.
I like to use the Enable/Disable NOTE ON parameters only, for any and all input blocks. In other words, the NOTE OFF is always left enabled for all input blocks, to avoid stuck notes. (your 3rd method).
This way I can, for example, play and hold a chord on a piano plugin, then step on my foot switch to disable the NOTE ON of the piano input block, and enable the NOTE ON of another input block that’s connected to an organ, and the very next keys I press will be the organ sound. So I could start playing the organ, and the piano sound will also sustain until I let up on the keys (or sustain pedal).
This keeps it simple on songs that swap between two instruments. Otherwise I use the VARIATIONS feature.
I get by just fine with my 16gig ram and predictive set to 1. I do not use the GP built in set list, but load each rack space as a single song into one large gig file. Works for me.
I will admit I did not spend much time with it, but when I tried Predictive Loading, I did not feel comfortable with it.
Also, I suppose another issue is my rig is not networked well. This is due in part to my CTK-7200 not accepting outside program changes and the fact, perhaps, that my Android tablets may be limited (I was not successful in connecting my tablet to my laptop). So, if I added 6-8 seconds to everything else I am doing between songs, it would be a problem.
But, now that I am pretty much transitioned to this new laptop, I am feeling more comfortable with my set up. I can access all my GP song at my fingertips in real time. Now IK’s B-3X is always well below 20% CPU (one instance, but playing both keyboards and bass pedals).
Have you actually measured this? In particular, (forget about samples for a moment), if a plugin takes X amount of RAM, duplicating that plugin will not use up 2X of RAM because the code part of the plugin is only loaded once. It is only the data that has to be duplicated.
So for example, if I load an (empty) instance of Decent Sampler, my Mac reports an RAM increase of 83Mb. But when I add another one, the increase is only 31Mb, same for a third.
As for samples, Kontakt (and as far as I know, Decent Sampler) play samples directly from disk and only preload a portion of each sample so even if samples take up many GBs on disk, that doesn’t mean they take up the same amount of RAM.
Also, purging samples is a very effective way to reduce the amount of samples that are actually needed.
I agree with everything you are saying here and purging ram in Kontakt is very useful.
I never did a real scientific test. But, I did post in the forum a while back some results when I removed about 8 instances of NI Session Horns (not pro) in rackspaces and replaced them with one instance in the Global Rackspace. I think that did seem to reduce ram usage.
Similarly, if you use variations of a (sample heavy) plugin rather than reloading that plugin, it makes sense that would use less ram.
So, I would say, just as purging samples in ram is a way of using it efficiently, I would think so is using variations (instead of reloading a sample-based plug in) and putting sample-heavy plugin “sounds” that you use often in the Global Rackspace.
Well, of course one instance is going to take less space but you can’t get instant switching from one set of samples to another if you only have one instance of the plugin
Also, if the developers did things properly then read only data like samples would be shared among multiple instances and not take double the space for the same samples. Would be interesting to see if Kontakt does that
But I guess my point is that it’s often not worth trying to manage resources yourself
Regarding my comment about my experience with predictive loading, I hesitated to mention this because I only spent about a few minutes trying it. So no one reading it should take anything from my post. (And, of course, predictive loading works for lots of users).
I think on my Dell (a bit underpowered) I seem to recall that when I skipped to a rackspace outside of predictive loading, it seemed to take longer than I expected to load. I was concerned it would freeze(?). I’m sorry, I don’t remember very well. But, based on my work flow, I ended up not going that route.
Of course. The benefit of predictive loading is when you are playing a set list in order. You can have spaces you will need “soon” loaded in advance so that you get instance switching just as if all rackspaces were loaded. GP is managing resources for you. It’s intended for systems that don’t have enough RAM
But if you try to select a song beyond the range, then the rackspaces in question AND those following have to be loaded from scratch which is why it takes longer.
Understood. Maybe it just took longer than I expected.
Sometimes I have to jump to unexpected songs during a gig. So, I pretty quickly decided, if ram was an issue, I would just create separate gig files for different bands.
But, the best option for me is to have everything available in a single (big) gig file. Luckily, I have been able to do this. And, as I fully transition to the Lenovo, this should work fine and ram should not be much of an issue.
