What do you think of having BLOCKS with multiple plugins inside?
Is like a insert a rackspace inside a rackspace.
With the possibility to edit and save them to use in multiple rackspaces.
And when you edit a BLOCK affects all rackspaces using it.
This way we don’t need to edit multiple rackspaces when adding new plugins to a duplicated one.
I know variations exist for a reason but this will save CPU and is an easier approach.
Great idea…I proposed this before though.
Rackspace inside a rackspace?
What about the physical layer, the widgets, scripting, routing, etc?
Are you really talking about rackspaces or reusing plugins?
Can work also.
“A group of plugins” or block that are in various rackspaces but edits to them happens in all rackspaces using them.
With the concept of using the global rackspace, is that “group of plugins” really necessary?
Does not hurt is like, having a prepared set of plugins to insert in signal chain, you can edit the set and it will change everywhere, i don’t want my guitar sims to be on all the time in global for example, and I’m using Nam that is CPU hungry for now. For lightweight plugins yes I will use global
I think that will not happen in the near future.
But for demanding plugins, why not use multiple instances of GP?
This way you can use multiple cores of your cpu.
I can imagine this is a lot of work and needs a way deeper thought than this single idea.
The problem is that in case of a crash (during a gig), which btw never happened, but I always want to take it into account, then setting up multiple instances is harder.
Another reason is that you only have one GUI, so you need to display global/local rackspaces from all instances, or forward all info from instances to a single instance that shows the GUI.
It would be really useful if this was done inside a single instance.
I sometimes feel the same - example: when just preparing a rackspace for a typical upper and a lower keyboard with ‘boards’ you have used in other rackspaces (Top: Strings from A, Bottom: Piano from B) it’s about losing the widget assignments when copying the bit’s and pieces together from the different wiring views, rackspace panels or your templates…
But on the other hand - that’s the architecture but flexibility of GigPerformer.
I’m still improving and adapting my ‘workflows’ to get things done smarter 
In general, I think that modularity should be the vision for a future major release of Gig Performer. It could happen on a few levels, depending on where the developers want to take it.
Here are a few examples:
The equivalent in Gig Performer would be to drop a module/device/unit onto your panel view (bolt the unit into your rack) and the associated plugin block would be added to the wiring view. All the knobs are ready to go and already connected to the plugin. You can move the UI as a group, but its layout and design are fixed. To change it, there would need to be a module editor. Update the module and all of the instances of that module gets the update. Want this module to be unique? Copy and paste it with a new name to create a different, custom UI for the same plugin block.
Module Groups - This is like the suggestion of the original post. Combine it with the above concept, and you can drop a UI onto the panel view that also loads multiple plugin units onto the wiring page with their internal routing already wired. For mixing, it you could have a custom channel strip. A guitarist might have a favorite pedalboard and amp combination.
Multiple Racks - This could be like multiple instances. (And this might be available only in a step up “Gig Performer Pro” or “Gig Performer Emnsemble” product. It’s not needed for a pedal board or synth selector/controller application.) This version would have a mixer layer and a layer for players. These would be like multiple instances that support multiple cores. There is one Setlist/Song/Part at any one time, and you can mix and match Rackspackes for the various players.
For instance, one song might use a Rock Kit drum library with a given sound, an Ampeg Bass amp, a Marshall amp with a small pedal board, piano, and a standard vocal chain. In the next song, everything stays the same, except it uses a Rhodes. The following song has a phone booth effect on the vocal. If one were to make Rackspaces with unique combinations for each song, it’s a lot of work, but by having independent racks for each player, you can build the overall setup by just associating different sets of Rackspaces for each Song.
The two use cases are where a whole band shares a single computer/Gig Performer setup, or when a solo or duo act with multi-instrumentalists does their thing. In my case, I do this with multiple instances today. I sing, play guitar and keyboards, and I have a Zendrum controller. I use MIDI libraries for all sounds, so I can either have it played by the MIDI File Player, or I can play it live - and the sounds are consistent between live and MIDI playback parts. As an example, I can play things, loop them, and get into the main verse, but MIDI playback can then take over to do the chorus or bridge. This means that I’m not stuck in a repetitive loop, and the sounds will be identical between live and playback.
Multiple instances do the trick for me, but an integrated approach could have benefits. First, it would be easier to set up, with no loopbacks needed, no separate applications, etc. Second, I could have both independent panel UIs (which I have now), and an integrated UI that controls things across the independent racks. For example, I could put the channel strips into the players’ Rackspaces wiring spaces and the submixes, effects busses, etc into the mixer level, but I could have a single, integrated mixer UI for live use.
A cool advantage is that I might get a better Marshall Stack plugin. I replace the old one once, and now all of my songs that use the Marshall get the update. Same thing with a Piano VST upgrade, etc. To be safe, I could save the previous Rackspaces and continue to use the old one on the songs where it was the better match.
Overall, Modularity can make Gig Performer much more efficient for the end user. We could make a UI set one time, and drop it into our Gigs. We could update that UI set one time and enjoy the update across all of our Rackspaces and Songs. We could avoid the tedious work of connecting UI elements to plugins over and over. We could use the power of multiple cores, but have the integration of one app instance and a unified UI.
We can (and should) leave the specifics to the developers. But the concepts of modularity, reuse, and working across cores (in a pro version) would be excellent goals for Gig Performer 5.0. It could retain the flexibility of Gig Performer, but reduce the repetitive tasks and ease maintenance for users. The more levels of modularity and reuse, the better!
I’m not sure this fits what you guys want, but,
I would perhaps mention Unify from PluginGurus.
I like that it can mix all kinds of plugins up in within one GP block,
including hosted effects with built-in mixer w/ effects sends/returns.
It’s seems extremely stable (Win11), w/ very small CPU usage, IMO.
It does spread your CPU load amongst your processor cores- one core per
layer --great for Omnisphere. Devs are great, (like GP!)
Alot to love, not much to hate (no audio inputs,yet). $79, there is a
demo to see if it works for you.
On edit: I agree- it would be even better if alot of that Unify stuff
was native to GP!
BUT: it does not support multiple outputs, only stereo
since 3 years the pro version is announced …
Hi PP,
Yes, I forgot to mention no stereo outs-- yet.
However, I did correspond with the main Developer of Unify
(ShaneDunne) about a month ago, and he said, the Pro version
is coming out a little later this year. It was implied to me
that it would address the multi ins-and-outs issue. And also
greater low latency (<128 buffer), and other Pro improvements
I’m sure.
Well, it works out as a pretty good companion, and complement to
GP—for me.
But, ya know, YMMV. 
Unify has no scripting, no rig manager, no free routing, no variations etc…
No it doesn’t…That is is what GP is great at. Unify (for me),simply gives
some extra, interesting, helpful functionality inside GP. Like a lot of other
plugins that operate inside GP. It’s a helpful tool.
I was NOT mentioning it as any kind of GP alternative at all!!
There are lots of plugins out there specifically for just hosting plugins
DDMF Metaplugin
Bluecat Patchworks
Yes, but I think it will have better performance natively.
Think of master rackspaces, you can insert them in local as a block, and pack a sound in a single block.
And anytime you make a change on those will affect to the others rackspaces using it.
Is like having presets that pack multiple plugins
Even if in use metaplugin or something, if I change something will have no effect on the other rackspaces.
I have as well, as have others over the past number of years. But, as you said, it gets quite complicated as one thinks about how an implementation would work.
As I thought about it, my concept was kind of along the lines of “object oriented”. e.g., maybe I have a small effects chain I use a lot, so I make that an FX “object”. In the wiring view it might show up as a single block, and to edit or see inside of it I’d need to click into it. That object, and others like it, might make up a larger object, which I might call “Guitar Signal Chain”. I might make a rackspace with three of those “Guitar Signal Chain” blocks in parallel, each of which contain multiple other blocks.
I think it’s a very similar concept to what @JonFair is calling “Modules” or “modularity”.
From a “wiring view” standpoint I think that stuff is probably pretty easy, but if it’s constrained to just “wiring view” stuff then it’s really just a copy & paste exercise and not terribly more advanced that the existing “Favorites” function.
To be useful, at a minimum (in my opinion) it would have to include a set of associated widgets, which would be automatically placed and linked when you add such an “object” into a Rackspace. That starts getting complicated.
Then you have the issue of “if I edit the ‘master’ object does that automatically flow through to every instance where I placed it?” Which gets even more complicated if adding or deleting widgets.
I like the idea, and it would be very helpful in the way that I use GP, but I’m not even sure how I’d want it to work at a detailed level.
I think this topic is useful to discuss periodically, and maybe over time a clear vision of how it might work can be crystalized.
That’s another one that I’ve discussed before. My conception of how it might work was having separate tabs for separate instances, like different worksheets in an Excel spreadsheet or the multiple tabs on our internet browsers. I’m not sure it really buys me much that I can’t do with multiple instances, other than convenience and potentially some kind of combined rackspace view. But, again, I’m not really sure how I’d want that to work.
To me both of these concepts are cool and useful. Whether they are cool and useful enough to justify the cost of implementing is a different question, though.
Regarding the editing of a Module and how that might affect the Rackspaces that use that Module…
This is similar to creating an effect (or generator) in Motion and then using it in Final Cut, or using After Effects within Premiere. Regarding Final Cut, it retains the previous version, and you can replace it with the latest version manually. It gives you some options related to clip length that would not apply to effects units and such.
In Motion, you can “publish” some parameters. For instance you can create a Title Generator and publish the text and font color. Then, when you use it in Final Cut, you can modify those properties. When you update the version in Final Cut, the local parameters are maintained, when they still align.
So yeah, there are ways to deal with versions.
To be more clear, when i save a group of plugins in favorite, the rackspace follows and recall the “.gpfav file” instead.
And if i edit the favorite it will change in all rackspaces using that “.gpfav file”. What do u think?