I’m just guessing what you mean:
I have a Kontakt for each instrument. If I have 5 sounds in a Rackspace that I create with Kontakt, then there are also 5 Kontakt blocks.
I’m just guessing what you mean:
I have a Kontakt for each instrument. If I have 5 sounds in a Rackspace that I create with Kontakt, then there are also 5 Kontakt blocks.
No wonder you need so much RAM even on that power machine.
You should think about using predictive load or use smaller gig files or replace some Kontakt instances by other plugins which do not use samples?
That’s exactly what I fear and don’t want. I programmed all the songs in six months with such high hopes. Now I have to reprogram them all. Ugh.
Predictive Loading: It seems there’s no other way to avoid reprogramming them. And hope that a technical solution will eventually be found.
I work similar to the way you have been trying to work. I have a lot of ram (120 GB) and a lot of rackspaces. I like keeping everything on a large gig file (sometimes creating a setlist from the Gig file for shows, especially if there is more of a rush to set up). If I think I am having an issue in the future, next step would be probably using 3 different (smaller Gig files).
Even with 120 GB of ram, I try to be very ram conscious.
Are you using the same memory intensive “sounds” on different rackspaces? I try to avoid that. I try to either re-use the same rackspace with the sound (modify the rackspace and use variations), or put the plugin in the Global Rackspace.
If I can get away with using a physically modeled sound, I try to do that. (Pianoteq, IK MODO Bass, etc.)
Maybe you can split that big Gig file into 2 or 3 (by band?).
Predictive Loading would be my last resort.
[FWIW, I wonder if there is an issue with Kontakt re-loading ram each time you save the gig file.]
My old computer only had 32 GB of storage. I could only fit 100 songs on it. Then there were always overload crashes. The new one has four times that amount. Only 60 new songs have been added. That makes me suspicious.
Yes, I have a separate rack space for each song. I didn’t compromise on that. I figured I could easily manage 127 GB.
I also have Pianoteq, but I mix it with a sampled piano. I simply like the sound much better that way than Pianoteq alone. That’s my problem, because I’m so sensitive to sound.![]()
I only play in one band, but we have such a wide repertoire. If I split the songs up, I’m sure that at one gig we’ll play exactly some songs that are in another gig file…
My experience is this: I purge Kontakt. Then I play the song a few times. During this time, Kontakt’s memory fills up with the played notes. Then I save GP. The next time I load GP, the exact notes from the last time are in memory.
This also means that the memory can fill up during a gig if I add new notes. If I also save GP there, then of course the RAM keeps growing. But I didn’t think I’d ever have problems with 127 GB.
Version 8 is already available. I’ve disregarded that one for now. However, if it changes the memory management in a way that reduces my problems, I’ll probably have to switch.
I think even with a lot of ram, you need to conserve (unless you use Predictive Loading). At least I do even though I have 120 GB. (When I start my machine it gets up to around 80%, but after about 10 minutes (as unused ram is released from start up) it currently settles at about 54% of my ram.)
If you use the same large piano library sound in multiple rackspaces, I think that adds up (same with strings, horns, etc.) (Atmosphere!).
There are very large sample libraries out there.
My approach is use physically modeled sounds when I can and re-use sample based sounds when I can, either by using the same rackspace for different songs (and using variations) or by putting it in the Global Rackspace.
Uhm, Predictive loading is the technical solution. It seems to me you have an unreasonable expectation analogous to trying to fit 20 people into a two-seat sports car.
If there isn’t enough RAM or even CPU cycles for an entire in-memory gigfile, then predictive loading will help by offloading/reusing plugins where possible. There are certainly tradeoffs, e.g. you can’t jump to an arbitrary song without any delays when you use predictive loading, but we can’t do magic!
I can’t tell how much ram you’re using (English speaker).
Did you implement the Windows optimization guide? Are you using Ultimate Performance Plan?
You’ve already made this comparison to me.
Okay. I read somewhere in the forum here that predictive loading might have problems and GP could crash. Is this likely, and if so, how likely is it?
The wait time wouldn’t be a big problem for me. In Logic, I sometimes had to wait 3 to 10 seconds before I could play.
I have 127 GB of RAM, but I’m using an Apple device.
Are you involved in the contact process? Under Multiprocessor support, you can distribute the processing power across the processor cores. Does distributing, for example, 5 cores improve performance or not? If not, I would suggest trying it.
Not GP, but rather a plugin that does not correctly implement the full VST API.
For example, we have found in the boast, that some plugins don’t properly handle a request to reset. It’s a legitimate operation but most DAWs never need to reset a plugin (because they don’t have a concept of reusing a specific plugin) and so developers either forget or don’t bother to support that part of the API.
Now, over the last few years or so, when we (or our customers) experience these crashes and report them to the developers, they generally get fixed for an update so it’s less likely today than it used to me.
That said, test, test, test, deeply before you do a show. Don’t just blindly turn it on at the last minute. It’s a very clever feature (my late partner came up with this) but the plugins have to be able to handle it
(He is using a mac)
Yep, sorry, strike that: “Mac Optimization Guide”.
I think there is a point here that may benefit from being emphasized.
Sample libraries are generally marketed toward composing on a DAW. I believe high end sample libraries are intended for people recording them for use in media, like television, film, etc.
Many of them have many thousands of .wav files to (attempt) to capture all/most of the articulations that the actual instrument is capable of.
DAWs have certain advantages in handling ram. For example you can archive tracks after recording them.
High end keyboards (Korg, Yamaha, etc.) have very litte memory compared to computers using GP. For example, their orchestral sounds include a tiny fraction of the articulations of most orchestral sample llibraries. They put a lot of effort into optimizing their sounds to sound good despite limited memory.
So, I guess the point is, if you are going to to use high end sample libraries, you definitely have to think about how to manage ram, even with 120 GB. Apparently, this applies to Apple computers too, even though (as I understand it) they do a better job optimizing ram than Windows based machines.
I’m probably being a bit extreme about it. Because I simply use a lot of sample libraries. But I’ve purged them all. I also don’t use many accents. I also had my second gig with GP this weekend. Technically, everything went perfectly. Only one song didn’t switch via the iPad. Probably a Bluetooth connection problem between the iPad and the MIDI patchbay.
With high probability - I would encourage you to use a wired connection
The computer is close to me. From my Logic days, I’ve always been in the habit of glancing at the Logic interface. But you’re right, a wired connection is always better. I might switch to a wired connection, since I already have a Stream Deck connected to my keyboard via GP. Could you perhaps give me your opinion on this thread when you have a chance?