[blog] Clever ways to optimize your plugin usage

Link: Gig Performer | Clever ways to optimize your plugin usage

Eight tips are presented in the article. In this thread we can share other tips or tips useful particularly for a specific plugin. :slight_smile:

Ideas are all from existing blog posts and community posts.

Honorable mentions:

Plugin specific tips:

  • MIDI Guitar 2 → (link)

Offload the processing of audio plugins to remote computers using AudioGridder - LINK

5 Likes

For users of Jam Origin’s MIDI Guitar 2

You might want to consider to use the standalone version of MIDI Guitar 2.

This way MIDI Guitar 2 runs in a completely separate space and your CPU is able to offload its processing out of your normal audio process thread which helps with the overall performance. Additionally, this will allow you to globally adjust the desired options in MIDI Guitar 2. Some references: this, this, and this post.

Also make sure to check this post by Tony Geballe where he explains how to extend the low end of your guitar range for MIDI Guitar 2 using Gig Performer.

Another tip for users that want to use MIDI Guitar 2 in the Global rackspace → LINK

1 Like

additionally to the section:
Plugin implementation and bypass
which links to this post from David-san:

Edit: i just made the post i´ve written here, a own topic in the tipps section.
you find it here:

2 Likes

Cool :slight_smile:

Of course, everyone is very welcome to present their tips :beers:

i thought you were asking for it, :wink:
but now i can´t find that sentence anylonger :laughing:
cheers

Unload everything that you don’t need for the particular sound. More info → YouTube.

Like Matt Vanacoro said - Make it lean and mean! :slight_smile:

1 Like

Some tips that @Ali_B shared on the Facebook group:

A couple of things I have done on very long signal chains. Firstly, using Amplitube 4 instead of Amplitube 5. For pedals there is no improvement to the sound in AT5. Way lower cpu.

Secondly setting the i/o of each block to mono. It doesn’t halve cpu use but it is a significant percentage if you’re on the edge.

TBH on sensible chains where each rackspace is targeted to specific sound (4-5 FX blocks) these are both unnecessary for me even on a 10 year old MacBook Pro using a 128 buffer size.

Running Diva at ‘great’ rather than ‘divine’ resolution and ‘multicore’ helps too, but I’m only using 3-4 note polyphony and my preferred patches don’t seem to tax the cpu.

Various logging options may also affect response times of plugins. Additionally, review options to see what is saved as a part of the plugin’s state, as otherwise your gig file may explode in size.

More information: Gig Performer | Gig Performer seems to be writing megabytes of data

2 Likes

Another tip: if you are using a plugin’s Persist mechanism (for example Omnisphere’s Live Mode), you may want to switch to Gig Performer’s MIDI Patch Persist feature. More info is in this blog.

EDIT:

It’s also a question of whether you are going to use (say) Omnisphere Live mode and stay in one rackspace. If so, Gig Performer’s Patch Persist feature is simply not relevant.

However, if you want to be able to jump to other rackspaces and have Omnisphere stay on until you release notes in another rackspace, then Gig Performer’s Patch Persist needs to be on.

1 Like

Tip for Amplitube: LINK + VIDEO.

From what I understand this is not a real direct-from-disk streaming, in the sense that the sample are streamed from disk only once when first loaded and not each time they are accessed, right?

I’m not a Kontakt expert, but this tip is related to changing the buffer size, i.e. what amount of data you want to keep in RAM. Basically, more data you keep in RAM and not stream from the disk, it is more likely to have a streamlined experience. On fast SSDs you can (allegedly) keep the buffer as low as 6 KB.

From what I understand, they load at least a 6Kb beginning of all samples and load the rest on the fly from the disk. But, my understanding is that once it is downloaded it stays in memory. It seems to be differed downloading rather than real streaming where nothing stays in memory once played. If it indeed works like this it is not only almost useless, but also dangerous. If I run short in RAM I prefer to know it at loading time rather then having to discover it the hard way while playing.

I understood like that, as well. One smaller (or larger, if you set it like that) is loaded into RAM and stays there, and the rest is streamed from the drive. Used instrument memory = number of samples * preload buffer size.

Perhaps these video may make things clearer:

2 Likes

Here is an in-depth video showing how to use Sample Robot and Kontakt.

1 Like