We are very excited about a new feature introduced in Gig Performer 1.5. It’s something we’ve wanted from the very beginning and it’s something that we believe many people will really find incredibly useful.
Normally, Gig Performer preloads all rackspaces, which means that all audio plugins that will every be needed are created as Gig Performer starts up. While this can use a large amount of RAM, particularly with audio plugins that depend on samples, the advantage is that you can switch instantly from any rackspace to any other rackspace and experience no glitching. At the other extreme, some audio plugin hosts load just one set of plugins at a time. That has the benefit of significantly reducing the amount of RAM you need but has the serious disadvantage that you can’t instantly switch from one set of plugins to another. It might only take 1/2 second, but that’s still not instant.
However, in many if not most live performance situations, musicians tend to follow a setlist. If you position your rackspaces based on the order in which you will need them, then with the new Predictive Loading feature enabled, Gig Performer will manage plugins dynamically as you move through your setlist. So while you are performing with one rackspace, the plugins for the next few rackspaces will be prepared in the background for when you reach them.
The results are amazing. Instead of requiring 10 or 20 gigabytes of RAM, you can get away with 2 or 3 gigabytes. Also, it turns out that a surprising number of plugins use CPU cycles even when they are not actually doing any audio processing. We have seen quiescent plugins add an extra 3% CPU utilization for each one loaded. So much of that overhead disappears as well.
Like most good things in life, there is a tradeoff but we think it’s a very reasonable one. If you use Predictive Loading, for the most part you cannot jump to an arbitrary rackspace and expect an instant response. You can only move instantly within the range of rackspaces that have been loaded. However, if you think about it, this isn’t really much of a restriction. You may be thinking that there are some rackspaces you really need to use often and now you can’t just jump to them. But you don’t have to. You can duplicate that rackspace as many times as you need so that an instance is available in every song. With this mechanism, you can have thousands of rackspaces without paying a significant RAM or CPU cost.
Take a look at the picture of a collection of rackspaces to the left. First, we can see that we are currently playing “Jazz Guitar” and it’s colored green. Notice however, that the two rackspaces before and after have faded green markers as well. That means that you can switch to any of those (but typically the intent is to switch to the next one) and have the usual instant glitchless response. Patch Persist, if enabled, will work also. So if you now click on (or use a MIDI command to move to) the next rackspace, “Choir Ohhh_E”, that rackspace will just work. However, while you are playing, Gig Performer will be preparing “Serum PD Quasor” in the background and it will also remove Choir Ohhh_A which it now presumes is no longer needed.
Rackspaces that are not instantly available have red markers on either side. If you jump to a rackspace that is red, then you will have to wait a moment while Gig Performer prepares that rackspace. Now, even in this situation, you mightn’t have to wait more than a second or two, it depends on what the plugins have to do but please don’t expect instant response in this situation.
We want to emphasize that Predictive Loading is not for everyone. If your live environment is such that you just have to be able to switch to arbitrary rackspaces on the fly, then you will have to have all rackspaces preloaded. That’s fine, it works very well, still using less resources than other audio plugin hosts, but you’ll still want to pay some attention to how efficient are your selected plugins in terms of CPU and RAM usage so that you can maximize your usage. By the way, here is the entire CPU usage of Gig Performer while Jazz Guitar is playing.
Yes, 8.7% total CPU utilization. The audio processing CPU utilization at this point was under 2%. Now obviously everyone’s system will behave differently and I’m using a reasonably modern iMac but you gotta admit, that’s pretty damn good!
Now, we have seen one or two plugins that don’t always behave properly in this dynamic environment. We’ve worked hard to optimize our system so that such plugins don’t actually fail but we have run into one plugin where it took an unreasonable amount of time for it to load its samples. We’re not ready to mention any names though. We do however need to be clear that in such cases, it is generally the plugin that is going to be at fault, the designer most likely having made assumptions that weren’t necessarily valid. In such cases, we will try to work with that plugin’s developer to resolve the issue.
At some point soon we will start maintaining a list of plugins that we have found to be reliable with Predictive Loading but so far we have found that plugins from Native Instruments, Arturia, GForce Software, AAS as well as a few individual plugins such as Repro (U-He), VPS Avenger and Serum work beautifully. Obviously we can’t have available every plugin in existence so we will also depend on reports from users to verify (or not) other plugins.
We will also soon be providing users with a little command line audio plugin exerciser. Unlike the plugin validation that most audio plugin hosts (including us) run to check that a plugin is safe to run, our plugin exerciser will do things like repeated loading, initialization and unloading of the plugin many times. In particular, it will load the audio plugin multiple times to see how well things go when multiple instances are trying to access shared resources. If a plugin makes it through that exerciser, we can have quite a bit more confidence in its stability.
.
Related topics:
– Predictive Loading (Gig Performer 4 User Manual)
– Predictive loading just saved my a– !