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.
