my question concerns the noise that can be heard upon switching rackspaces from one to the other. it is obvious that this is related to the CPU usage / buffer size numbers. in this case, i use rackspaces that run flawlessly around 50-55% CPU usage, with no noticeable peaks above. i also fumbled with the fade out and input mute times of racks but it did not really make a clear difference.
however, i noticed that i am sometimes getting no noise and sometimes a lot. despite trying different things, i was not able to find a clear logic behind it and would like to learn more about what exactly causes and influences the amount of trouble i can expect switching presets.
hereâs just two suspicions:
my presets often involve long delays and reverbs and i realized that i can create a lot of noise by switching them more often, maybe before some kind of background processing is completed? when i switch back to one of the racks on which i interrupted delay/reverb tails, the rest âfrom last timeâ seems to be still hanging in there - like it is trying to after-deliver what i cut offâŚ
not playing / providing no input, and waiting until all delays/reverbs have rung out, seems to improve, but not to avoid the problems.
so, the lesson i should build patches up to maybe 30% usage and set my buffer soze to 1024? i am sure somebody here can explain the inricacies of switiching presets as smoothly as possibly.
What version of GP are you using?
How looks the Output Fading in the rackspace properties?
Are you using MIDI patch persist?
Are you using predictive load?
What are your audio settings in gig performer?
How looks your wiring view?
Are you using scripting?
Do you use different plugins in the rackspaces which introduce different latency?
Are you using only Audio, no MIDI ?
How sounds the noise?
Is it occurring even when you do not switch rackspaces?
During the fade time both rackspaces are active, so if each rackspace needs 60% cpu, it would add up to 120% cpu, which is obviously too much. If the fading times are reduced to zero, the rackspaces would not be active simultaneously, but the switch from one rackspace to another would be rather blunt and that may also result in an audible click.
From cpu perspective zero fade is the most advantageous. From a sound perspective at least some fading would be best, as long as the cpu usage is not too high.
Maybe you could bypass some cpu hungry plugins from the rackspace thatâs being deactivated, just before switching rackspaces, but that will probably require some scripting, also to un-bypass these plugins when the rackspace gets activated again
Do you use different plugins in the rackspaces which introduce different latency?
yes the plugin monitor sais 0ms in most cases, but e.g. the unfiltered audio silo (grain delay) reportedly has 1400ms, and all the guitar rig instances 16ms.
Are you using only Audio, no MIDI ?
only audio
How sounds the noise?
itâs the typical glitch sound iâve known e.g. from experimenting with much too intense patches (i generally stay below 50%) - it sounds like a buzzing digital glitch. itâs at one pitch, distorted like through a ring modulator, sustained but very irregular in amplitude.
Is it occurring even when you do not switch rackspaces?
no.
ok i might have a clue, also in regards to the above question about plugins with different latencies, where i mentioned the widely differing latency (1400ms vs. most plugins with 0ms) of unfiltered audio silo / granular delay.
actually, the irritations have only come up to this degree recently. just double checking the newer patches in my setlist again, i find the most problematic ones are indeed using this plugin, sometimes several instances.
would there be something to be done? i read GP takes care of the adaption, but this number just seems out of proportionâŚ
A bit of a reality check here â as mentioned above, when you use patch persist (or you have audio tails in the case of just audio), you are going to have to deal with two rackspaces running simultaneously during the cross over and if you instantly need all the plugins in both rackspaces to be active, the plugins are absurdly CPU intensive - maybe not intended for live performance, and you donât have enough CPU cycles or a sufficiently good audio interface driver (some really are better than others), then you may certainly get glitching.
So there are several ways to deal with this but it will require experimentation
If you donât need all the plugins in the new rackspace immediately, then configure them so that the ones you donât need start bypassed when you first enter the new rackspace. You can then unbypass them either manually or using GP Script, perhaps using the TriggerOneShotRamp() function
You might be able to use the envelope follower plugin to track the level of the old rackspace values so as to arrange to have the plugins in the new rackspace to be automatically unbypassed when the sound disappears from the old rackspace
You might think about using two GP instances and putting âalternateâ rackspaces in each one so that when you switch rackspaces, you are actually switching to another instance, which will use (hopefully) a different CPU core.
There are probably other ways that I havenât thought of.
These days 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. The âspikeâ during the rackspace changeover is kept around 30%, even in the most demanding rackspaces. This affords me a great deal of latitude when creating rackspaces, as I donât have to concern myself as much with sacrificing great plugins for more âpracticalâ ones.
possibly, cpu seems not the only issue here. is there anything to accommodate the afore-mentioned, significantly different delay times of some plug-ins? i have clearly more cpu-intensive rackspaces that switch more or less flawlessly, but the recent ones with instances of a certain 1400ms-delay plugin make the most trouble. the plugin itself is not particularly cpu-hungry! when i remove it for a test, the change in CPU load does not change by more than a perscent or two. so i would think that the inehrent plugin-delay is part of the problem.
This occurs with certain plugins that arenât properly clearing their buffers in this scenario. They are technically supposed to, but many donât. I know that Valhalla and MeldaProduction reverbs and delay donât have this problem â the buffers get cleared when the plugin is bypassed so the tails arenât present when the plugin is active again.
Which plugins are you using for your reverbs and delays?
thank you for your time and hints - as mentioned above, Unfiltered Audioâs Silo seems the problem here. In addition, during the time when these problems occured increasingly, i also started using Audio Thingâs Fog Convolver and Heavyocityâs Vast, but only Silo lists 1400ms delayâŚ
I know that Fog Convolver also has this problem. I donât have the others you mentioned, but I suspect they might also.
A lot of manufacturers design plugins for studio/DAW use, where the usage scenarios are different than for live performance and switching of sounds etc. As a result the buffer clearing part of the coding seems to get forgotten or left behind. If youâre using a DAW, with the plugin as an effect on a dedicated track, youâd never come across this issue because you wouldnât be bypassing the effect â youâd mute the track itself.
So, you can contact the manufacturers and tell them the issue, that youâre using their plugin in a live scenario and need the audio buffers to be cleared once the plugin is bypassed. Perhaps theyâll include the fix in a future update. In the meantime, the two manufacturers I listed earlier are ones you might look into as replacements.
