In this article you will learn about tips and tricks to optimize your plugin usage.
Tips compiled in this article are based on independent tips that can be found in our community by users who wanted to tweak their setups and reduce even more their CPU and/or RAM usage.
Sample it!
.
Gig Performer v4.7 and later include the Auto Sampler, a powerful and revolutionary feature that allows users to create a set of samples from individual or interconnected plugins that, if used together, might demand too much CPU to be practical for live performance. External synths can also be sampled with added plugin effects, eliminating the need to bring those heavy synths to a show.
Note: there is a new Auto Sampler YouTube video — check it out here.
Create your own impulse responses
.
If you particularly like a plugin’s room effects but when that effect is engaged, CPU usage jumps up substantially, then you may want to create your own impulse responses.
Read this article to see how our community member and beta tester @rank13 managed to reduce his CPU cycles significantly (25% instead of 50%) by creating his own impulse responses.
Try physical modeling plugins
.
If you like sample-based plugins but you do not have enough RAM or disk space to store all the samples, you might want to try a physically modeled plugin as an alternative. For example, Pianoteq from Modartt creates a physical model of an acoustic piano, so it doesn’t need gigabytes of samples. Pianoteq supports sympathetic resonance, something not really possible with sampled pianos and has addons for physically modelled electric pianos and clavinet.
Applied Acoustics Systems has physical modeled plugins for several synths, string machines, guitars and even a modular rack.
See this blog article and this thread to learn more.
Use multiple instances of Gig Performer
.
Using multiple instances are covered in detail in this blog article:
If you use a plugin such as Diva or Tyrell N6 (as pro musician Alistair Begg describes in this post) that are notorious for having high computer resources requirements, you can put it in a separate Gig Performer instance.
Another benefit is that your other instance can use with a different buffer size, say 256 samples – just make sure that the sample rate (say 44,100 Hz) is the same across your instances. Read this blog article to learn how buffer size and sample rate affect your computer resources.
Get to know your plugins and tweak them
.
A little bit of reading the documentation or researching your plugins can be helpful. For example, if you are on a Mac and plan to migrate to Apple Silicon, you should check whether your plugin is natively available for your M1 chip or whether you need to run it under Rosetta (NB: Gig Performer is natively available for Apple Silicon). Of course, we recommend that you use plugins built natively for your processor to have the best performance.
Further, certain options in your plugins may cause CPU spikes or other undesirable behavior. For example, as described in this article, we strongly recommend that you disable the Usage Data Tracking option in Native Instruments plugins and look for similar options in other plugins:
Also make sure that you disable any automatic update or automatic install features for your plugins. NB: Gig Performer itself does not share usage data.
Gig Performer supports VST, VST3 and AU plugins, the latter on Mac only. However, sometimes certain formats are not as well tested as others and a VST version may work flawlessly while the AU version fails, or vice versa. For example, some plugin formats may crash but the same plugin in a different format may work just fine (see an example here). It can also happen (although very rare) that different features are supported in different plugin formats (see examples here, and here). Therefore, test your setup thoroughly and select the most stable and efficient plugin format.
The documentation for specific plugins may also contain tips to reduce the load on the CPU (here is an example).
Use Scriptlets and scripting
.
Although GPScript was initially developed for specialized MIDI transformations, it has morphed into a robust and sophisticated programming language tailored to the needs of musicians. This blog article explains how Gig Performer provides you with extremely flexible MIDI processing options and may save you from having to download or buy additional plugins or applications.
Gig Performer 4 introduced Scriptlets, allowing Gig Performer users to create their own MIDI and OSC processor plugins using GPScript. The best thing is that they can be easily reused – you don’t need to know programming to be able to use them. For example, see this useful scriptlet that implements a version of polyphonic aftertouch for keyboards that don’t explicitly support it:
So, if you don’t have a keyboard with Poly Aftertouch, this scriptlet will allow you to have this functionality! (and it works remarkably well, see here). No third-party plugins needed.
Find other useful scriptlets in the Gig and Rackspace files forum, a repository for many creative ideas of our community members.
Use the Predictive Loading feature
.
In normal operation, Gig Performer loads all plugins for all rackspaces and does some optimization to reduce the impact of hosting a large number of plugins simultaneously while still allowing you to switch instantly from one rackspace to another, even in the middle of a bar.
If your computer has limited RAM or your setup highly relies on a bunch of samples, Gig Performer’s Predictive Loading feature can be of great help:
Make sure to also check this real-life anecdote with Gig Performer and Predictive Loading.
There are two benefits to Predictive Loading. The first is that by reducing the number of plugins that are actually loaded at one time, you reduce RAM requirements significantly. You can still go to any rackspace you want but you might have to wait for a plugin to load. The second benefit is taking advantage of “proximity” to preload (and unload) rackspaces so you can get the benefit of instant switching, if you are following a setlist.
Replace plugin features
.
It can happen that activating a certain plugin feature can lead to unwanted behavior such as occasional CPU spikes, significantly higher CPU usage, or even add more latency. In these cases you may want to use a different plugin in your plugin chain and improve the overall stability (or just improve your sound, like Robert Martin in this post). NB: to see how much latency a plugin block introduces to your setup, simply hover with your mouse over it; click here to learn more.
Many of these specialized plugins may be free, so make sure to check our list of free plugins here.
Plugin implementation and bypass
.
The plugin implementation itself is also one of key factors to consider. The thing one sees sometimes with poorly developed plugins is that they spawn off a bunch of threads that they just leave running and since those threads are not directly involved in audio, they suck up CPU cycles even when they’re not doing anything. In that situation, even if you put them on different rackspaces, they’ll still suck some cycles.
This issue has been brought up many times in our user community. If you’re seeing significantly higher CPU levels when you have a plugin in rackspaces that are not “Active” or CPU cycles are high even when a plugin is idle, then one or more of the plugins in those other rackspaces are poorly implemented. When you switch away from a rackspace, all plugins in that other rackspace have their audio processing disabled. However, if they are still using a lot of CPU cycles, that means that they have lots of other threads running all the time as opposed to just when:
– audio processing is needed,
– or the plugin GUI editor is open.
See examples along with videos here and here.
Therefore, a decently implemented plugin should reduce its CPU usage almost completely (see examples here) when it is not generating any sound (or when it is bypassed). A useful trick is to bypass a plugin or plugins when the volume is reduced to zero. You can accomplish this:
– using widgets groups (see this post)
– or scripting (read this blog article for the detailed guidelines).
While observing CPU cycles and determining how your plugins behave, note that Gig Performer shows only the CPU cycles used by the audio processing. That’s completely different from overall CPU usage which you would see using the Windows Task Manager or the Activity Monitor (read this blog article to learn more).
To see more tips or share your own tips, visit this Community thread.
.
Share this article to support Gig Performer and spread the word! 
Own The Stage® with Gig Performer®
Nemanja Pudar
.
Related topics:
– How to offload the processing of audio plugins to remote computers using AudioGridder
– Community Tips and Tricks
– The Ultimate Guide to optimize your Windows PC for the stage (e-book)
– How to optimize your Mac for a gig (blog)