Global change persists after changing local widget

I have placed effects in my global rackspace. In the local rackspace I have a widget to turn on the Chorus effect. But when I go to a different rackspace, the Chorus is still turned on in the Global rackspace. How do I make it so it doesn’t persist in the next rackspace/song change? I will never remember to turn it off again before changing!

Create a widget in each rackspace to control the global widget.

That seems like a lot of redundancy if you have a lot of rackspaces. Is there a script or something that would turn off the effects in the Global rackspace when I exit a rackspace/Song?
This is what I have set up in my Global rackspace:

It would be easy enough to create a script that will turn them all off every time you switch Songs, Songparts, Rackspaces, or Variations.

But is that really what you want? All your effects to be off every time you enter a new Song/Rackspace and you have to remember to turn them on again?

Whatever behavior you want can certainly be accomplished with some combination of scripting and linking widgets between the global rackspace and regular rackspaces. In most situations I think what @pianopaul suggested is the best solution.

You can use a rackspace script to turn of the effect when leaving the rackspace.
And why use a widget to turn on/off the chorus?
You can use a routing in the local rackspace to send only to chorus when needed.
For example channel 7+8 in the local rackspace /(“To Global Rackspace” plugin) is for using the chorus which is connect to channels of the “From Rackspaces” plugin.
So your routing decides to use the chorus.


The whole point is that plugins in global rackspace are global and won’t change unless you explicitly change them

As a poor analogy, suppose you have a multi-channel mixer with different sounds arriving on different faders — your mixer has a global EQ, perhaps some reverb or compression. A channel strip fader in the mixer corresponds to a rackspace in GP

You do not expect that global EQ or the effects to change just because you soloed a different channel strip. If you want those things to change, then you either insert the effects in each channel strip (i.e, insert your effects in individual rackspaces in GP) or you have a mechanism to cause the global settings to change when you switch to a different fader (rackspace).

The latter is done by using local widgets in the rackspace to control the global rackspace settings. Think of the global rackspace as just another fancy plugin that is always available.

I think I like this idea better. If I’m getting this right, I would put each effect on a different channel on the From Rackspaces block and one that bypasses them, then route the effect that I want from the local rackspace to the correct channel in the To Global Rackspace block. Thank you, that should work for what I need

Thanks for the clarification. I’m learning as I go! Loving this product so far.

1 Like

I’m taking a guess here based on your images, but it looks like maybe you’re using TH-U for effects.

Just to give you an idea of the un-importance of having effects loaded in every rackspace, I actually use at least three separate instances of TH-U in each and every rackspace in my guitar rigs. I have an FX-only instance of TH-U first, then into a mixer, then to an amp-only TH-U, back out to another mixer, then into a speaker cabinet only TH-U, then to a mixer. I generally use a separate EQ plugin either pre-or post all that, and a separate reverb between the amp and cabinet sims. I’ll sometimes have a separate compressor VST before all that, sometimes a digital delay after all that…

The loading times and RAM usage on those is pretty low. I prefer the simplicity of having everything in the signal path in an individual rackspace. The reason for my having multiple mixers between the multiple TH-U instances is to see and set signal levels at each stage. It makes my life a lot easier when creating and editing presets.

I’ve learned to keep my “architecture” in my gigs relatively simple unless there is a really compelling reason not to. For example, if I’m using something very load-time and memory heavy in a lot of racks, I’ll put that in the Global rackspace if it’s practical.

A great thing about GP is there are a lot of different ways to achieve what you want. No right or wrong answer. But when the goal is “efficiency” I find that maximizing my own efficiency at creating and editing rackspaces is more valuable to me that maximizing RAM or CPU efficiency. I don’t mind letting them do some work. It’s what they’re made to do.