Hi Team,
Regarding the upcoming features: please ensure that both Standalone Blocks and Container Blocks support Memory Deduplication.
If any block (Standalone or Container) shares the exact same state across different Rackspaces, GP should reuse the same instance in RAM.
There is no need to reload. Keeping the block (Single or Container) “warm” across the entire gig saves RAM and ensures the fastest possible transitions. The principle should be: same state = same memory address.
Best regards.
Please help me, what are container blocks?
As soon as you change ONE parameter of a plugin, the state becomes different.
What do you think is being reloaded?
Switching rackspaces now is pretty much instantaneous – what exactly is not fast enough for you?
Apart from the question from @pianopaul: GP is a plugin host, not a virtualization platform. Each plugin interacts directly with the OS when it comes to allocating and freeing memory. Furthermore, even an advanced virtualization platform like VMware ESXi only recognizes zeroed pages, so no deduplication (at least, not that I’m aware of).
What upcoming features (are they confirmed by the devs?) are you talking about?
If I duplicate a Rackspace and the plugin state is UNTOUCHED, GP should point to the same memory instance instead of creating a new one.
Regarding Containers:
The idea is to have a “Global Container Block” that works as a single instance across multiple Rackspaces.
The goal is to allow us to choose when a block (Standalone or Container) should be “Global/Shared” to save RAM, without the routing complexity of the current Global Rackspace.
I don’t know how it works internally, maybe the only way to work is to load the entire patch in memory, I’m just saying load only what is different inside a rackspace, and rehuse what is already in use by other rackspaces if it is untouched (same state)
From the point of minimizing RAM usage: If you use the same block in two rackspaces it might need to be active multiple times (for example when processing an audio tail, or MIDI persistence). Because the audio sample buffer is part of the state of the plugins, you would end up using 2 separate instances of the block, thus taking up more memory than just one instance, so no gain there.
I agree from a design point of view, blocks/containers could be useful.
What exactly is the problem you are having that is causing you to make this request?
I’m thinking about “Modular Rackspaces” or “Sub-Rackspaces” (Pre, Middle, Post).
Instead of one Rackspace, we could assemble patches using modules. For example, a single “Middle Block” (with a heavy amp plugin) stays loaded once in RAM, and I just swap different “Pre” (pedals) and “Post” (delays) blocks around it.
Regarding potential clicks or audio drops: This could be handled by a micro-crossfade between the swapped modules while the “Shared Core” (Middle Block) keeps processing audio uninterrupted.
This would allow us to build patches by “assembling” shared cores. If 10 patches use the same Middle module, it stays in memory once, but I keep the flexibility of local routing.
What do you think about this modular approach?
I’m just imagine don’t take it bad
No worries. I think other people also suggested things like this one way or the other.
The only thing is that perfectly simple ideas are not always simple to implement or even possible.
GP is designed to operate as a real-time, live performance host-- in other words, a high performance app. What you’re suggesting regards conservation and efficiency, which is not a concern of an app of this type. That is a hardware/user responsibility to have a machine capable of handling the things the user wishes it to do, and plugins that are coded well for live puposes. There are ways already provided in GP to accommodate for machines that are struggling i.e. use of the Global rackspace, Predictive loading etc,. Ultimately, upgrading hardware is always going to be the long term solution.
Keep in mind that ‘high performance’ and ‘efficiency’ are on opposite ends of the spectrum of all real world products.
Making a new copy means allocating (lots of) memory. The OS might need to block the requesting thread while satisfying the request, and this might lead to severe dropouts in the audio stream
Well, right now I think you’re suggesting an impractical solution for a problem we don’t have.
Which will happen numerous times per millisecond if you are turning a knob or slider that adjusts any parameter in a plugin!
That’s the last thing one wants to do in a real-time live performance application and based on detecting changes to a plugin, you’d end up loading hundreds of new plugin state.
this will lead
Just wanted to break it easy to the OP 
You put the “Middle Block” in the global rackspace and then you use different rackspaces for each set of Pre and Post
I understand the request. This is similar to my suggestion of allowing the user to use an “alias” or “clone" of an existing plugin, here:
https://community.gigperformer.com/t/ill-add-two-here/21230
(I think this is not so easy to implement, especially cosidering the need to prioritize code changes, and the overriding imperative of keeping GP rock solid).