GP3 for FOH live plugin hosting - Setup and workflow

I’m a FOH sound engineer, and I’m looking into replacing my current plugin host (Live Professor 2) with GP3.
I initially thought GP3 would be ideal for my setup, but after a couple of days fighting to understand exactly the workflow and capabilities I’m a bit dumbfounded.

1: My initial idea was that I could build several racks working simultaneously in tandem, where each rack would be the insert path of the different channels from my Mixer.
Have I misunderstood completely? It seems only one rack-space will pass audio at a time?

2: Would that mean I would need to put all the plugins I use in one rack space, and then build all the insert paths within that one rack space?

3: If question 2 is correct, that would mean I need to build all widgets also within one rack space. Are you unlimited in the amount of rack panels one can put in a single rack space?

4: I need some plugins to always recall settings within a song part, and others to never recall anything and be completely safe from any recall (Like the plugins in the insert path of my master bus). Is this possible?

5: Rack Variations: Lets say I have 20 songs in a set with 5 parts each song, that amount to 100 “variations” in a set. Would I need to make a rack variation for every part of every song?

6: Is all plugin settings stored within a song part, even though they are not mapped out to a widget?

I probably have a ton more questions, but I guess this is enough for a start. Hopefully someone here can help me out, I’m starting to think my needs and usual workflow isn’t matching up well with how GP3 is meant to work.

In SetList Mode the song parts are referencing rackspace variations.
This way you can reuse variations, so when you have 100 Songparts you need probably much less variations.

Plugin settings are stored as state in a rackspace.
The widgets can be mapped to plugin parameters and the value of a widget is stored in a rackspace.
So when you change parameters which are mapped to widgets and you save to gig then this plugin parameters are recalled by the stored widget values.
All other changes of the plugin are stored as state in the rackspace.

You could route your master audio to a 2nd instance of Gig Performer where you place your master plugins.
So in the 1st instance you build your individual effect chains and route the audio to the 2nd instane which acts as you master chain.
On Mac you could use for example Blackhole or Loopback.
On windows there exist similar virtual audio drivers.

It is more that only one rackspace is active at a time, but you can have as much audio connection as you want in one single rackspace. If you want to work simultaneously on independent rackspaces, then you can open other GP instances with these rackspace. I here suppose that your audio interface drivers is multi client.

That’s indeed a way to do it.

Rackpanels are only the front end of the connection view. You can put a lot, but as a keyboardist needing to access them on the same touch screen I usually stop to what I can display simultaneously :wink:

For the other points, nothing to add to the answer of @pianopaul.

I suppose that this is because, as a FOH engineer, you are used to think of complicated bus connections rather than of simple wired connections. I think you will need a bit of time to play with GP and to figure out how it can satisfy your needs. As a keyboardist I am probably not the best person to show you some direction, but as you are note the only FOH engineer that adopted GP there is obviously a benefit to use it for FOH :wink:.

Maybe that s was interesting

You can achieve any kind of behaviour here by using the combination of widget properties.
“Ignore variations” option for a widget will always keep that widget at the value you set it regardless of a variation for example.
Each song part can also have an “override” of a variation. You can have some basic settings, but for a certain song you want to change the EQ a bit for example - you can modify it using widgets and then store that as part of the song part without the need to create a new variation. Now that song part will always recall the values properly while others will use the base setting you have in the variation.

As @pianopaul already mentioned… Rackspace is a set of your routings and effects. Variation is a widget-based modification of some plugin parameters within that rackspace. Say you have a simple rackspace with only one reverb plugin in it. You could have a widget that controls the wet/dry mix. You could now have 3 variations that are called dry/mid/wet each having that widget moved to the appropriate position.
Now you use these variations in your song parts. You REUSE them when possible so you don’t need to create a new variation every time. If you need slight modification for a song or two then I recommend you use the variation overrides within the song part. If you use the same settings in multiple songs then it’s easier and better to create a variation.