In another recent thread there was a discussion about the CPU peak that users face when switching rackspaces. With audio tails on or MIDI Patch Persist in use, there is a time when the processing load of both rackspaces is active. This can cause audio pops/glitches if you have some CPU-hungry plugins in both rackspaces.
I use Audiogridder in local mode for all my CPU-hungry plugins. Not only do I get the benefit of load balancing, but during that time when two rackspaces are running simultaneously my CPU usage remains low.
For this example, I have three instruments in two rackspaces. When played, the CPU usage rises to ~40%. During the switch to the other rackspace, the CPU usage jumps to ~70% for a moment. This could easily cause an audible pop in certain systems (this particular old laptop included).
I can alleviate this problem with Audiogridder. I set it up in local mode(meaning the server is running on the same machine as the plugin client).
Then in each rackspace, I use the Audiogridder plugin and within it I load each of the respective instruments. I get great CPU load balancing with this method at the cost of a small amount of latency.
Now, when I play the instruments you see the load is significantly lower – and when I switch rackspaces the CPU usage never goes above 15% – all using the same instruments as in the first example.
Here’s a great tutorial blog post written by @npudar about Audiogridder.
You simply use the server app and plugin on the same machine. I set the Screen Capturing mode to Disabled(Local Mode) so that the plugin UI doesn’t display twice.
Then when I open the Audiogridder plugin inside GP, I look for that IP address and connect to it. That’s it. After that, every time I open the Audiogridder plugin it will always first look for and connect to that IP address.
