I think I’m starting to see why loading all my synth plugins into the global RS is not a good idea. With only10 synth plugins, my CPU is at 95%. Normally it is sub 40%. This I did not expect! I thought with predictive loading turned OFF, GP would normally be loading all the plugins in every rackspace. I actually expected to save CPU b/c I am not loading multiple copies of the same plugin. So what is going on here? It seems even with predictive loading turned OFF, GP is only loading one rackspace worth of plugins at a time, or at certainly at least not all of them? Otherwise why is the CPU usage so much more when the plugins are loaded into the global rackspace?
Because all plugins loaded in the global rackspace are active.
And bad coded plugins consume CPU even when not played,
That is 1 advantage of local rackspaces.
So loaded vs active are different? Because with predictive loading off, all plugins in all rackspaces are also loaded right?
Yeah, this is why it’s important not to try to replicate the model of other systems.
Properly behaved plugins in rackspaces that are not currently active will not use significant CPU cycles which is why I said you should just load your plugins in multiple rackspaces.
You have to be very careful here. Loading 10 instances of a plugin does not take up 10 times as much memory. Only the data will take extra space for each instance.
Well, understanding this changes everything. Learn something everyday! Thanks for clarifying!
That’s why I made this:
But, using one unique multipurpose Rackspace has limitations compared to using several local Rackspaces. I explored this concept here:
It is quite tricky…
So…I need to further understand how the “engine under the hood” works. In GP, we have these plugin states (maybe more, but for the sake of this discussion):
1: loaded plugins
2: active plugins
3: bypassed plugins
I took a look at your very helpful gig file (thank you!) and the CPU was very low when most of the plugins were loaded, but bypassed. As I un-bypassed the plugins, the CPU started to increase. Does that mean then that bypassing plugins is the same as loaded plugins but not active? Meaning similar to having plugins in different rackspaces (with predictive loading OFF) but only those plugins are eating CPU that are in the “active” rackspace? For example, if I have 15 plugins total in 3 rackspaces, 5 in each RS, is it the same CPU usage as having all 15 plugins in the same rackspace with 10 always bypassed and only 5 not bypassed (active)?
If that is the case, my original idea “could” work with loading a bunch of synth plugins but instead of just using the “note on” filter, I could bypass the plugin to free up CPU and with you plugin persist scriplet kind of have best of both worlds??? That seems pretty sweet! I can see where loading plugins into seperate rackspaces is still to be preferred, but in my case it might be a good trade off…if I’m right about what I think bypassing means to CPU…
I cannot answer all of your questions as I don’t know everything, but bypassing a plugin only spare a CPU if the plugin is well programmed.
I think there is a difference when bypassing the plugin itself or bypassing the Gig Performer Plugin Block.
When I really have to bypass I do that with the Plugin Block.
But I do not like such tricks.
So, what is supposed to be the difference?
Some plugin when bypassed just do not heavy process audio but remain active, so consuming CPU.
When the plugin block is bypassed then no CPU at all should be used.
Because unbypassing for there 1st time sometime causes Audio spike,
For example Hammon VST from IK multimedia.
Workaround before playing, bypass .- unbypass - bypass.
Did you tell it to IK?
Not yet, I told them some other issues, but got no reaction.
What is amazing, in Parallel I play Solina Strings Arturia and when I unbypass Hammond VST for the 1st time then Solina gets a short audio mute !?
I just loaded about 10 Arturia plugins in the global rackspace. Before loading them CPU was at 10%. After loading them it went up to 60-65%. When I bypassed them all, CPU went back 10%. Good news! So at least with quality plugins, this works.
Actually, what is really a good demonstration of the quality of a plugin is one where the CPU is reduced significantly as soon as it stops producing sound, even without bypassing it.
Interesting! Arturia definitely doesn’t behave that way!