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
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.
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.
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.