Inspecting more the gigfiles on a text editor I can see some huge numbers in properties.
For example:
Good vs Malformed
1 example: 3253.3oc6 etc… vs 2236996.3oM6 etc…
2 example: 6183.3oM6 etc… vs 2221632.3oM6 etc…
don’t know if that means something useful.
The plugin in question is “Mini V3.vst”
In the “good” rackspace - it’s state takes a VERY small amount of the gig file while in the “bad” one - it’s several megabytes.
Somehow “Mini V3” saved a state that seems to be huge and invalid.
You can try to re-insert it into that rackspace and then save - see if that makes a difference.
Yes that’s work for me!. Problem solved.
Now… is this problem Arturia Related o Gig performer one?. If is Arturia I can post a ticket to their support staff.
Thanks for all.
That’s an excellent question. Gig Performer requests the state of the plugin and just gets back a chunk of data. If GP was screwing up what it gets back, I’d expect this to impact plugins all over the place. Since we haven’t seen that, it’s hard to know the root cause. However, I’m wondering if this is something that can be reproduced. Do you remember when this started happening and what you were doing (e.g, tweaking parameters, duplicating the rackspace, making a copy of the gig file, etc?)
It occurs to me that an interesting experiment would be to load the “broken” gig file, tweak the Minimoog, then save to a different file, quit and then load different file
I have just test that experiment and It not seems to improve, also I noted during the test that the plugin GUI reactions to tweaks is too slow (like a lagged GUI), only just that rackspace take a whole 8GB RAM, that is insane, don’t really know how I ended with that.
I think that maybe the problem arise by creating a lot of rackspace and instance of that plugins and tweaking those but not saving preset, also I keep creating copies of a gigfiles then made modifications over that (for example my current gigfile is the 14th copy or version of an original one). But I can’t recall something more different than that.
I would like to arise this post again. Unfortunately the proposed solution was only temporal but not for a long term.
The problem is that, for example, using five Arturia’s V-Collections plugins loads 5.5 GB of memory in gigperformer when using the gigfile (provided below). The gigfile (arack.gig) attached in this post includes only just one rackspaces with five plugins.
arack.gig (1.4 MB)
This scenario happens only for some Arturias plugins like Mini-V3, Piano V2, but not for all of them.
Using Cubase as a comparison and loading the same plugins it takes 800MB of memory. So there is really a big difference. The problem mentioned doesn’t seems to build up on Cubase.
The proposed solution consisted on cleaning the Rackspace and create a new one with the same plugins, but this is really difficult to do in my environment where RAM usage is so high that changing between Rackspace take a lot of time, and also there are more than 1 Rackspace affected by this.
An strange thing that maybe is related is that by inspecting the Rackspace file. when creating for the first time it size is relatively small, say for example 70kB but then begin to increase when saving and it sizes could be like 5MB (and they are simple rackspaces). Some plugins seems to return bogus states.
I need help for this, some kind of direction, I can’t keep people wait for 2 minutes between songs changes. Don’t know if it is a Gigperformer or an Arturia problem, given the details…
When you did your comparison using some other plugin host. Have you done the same thing that you are doing in GP? Loading the plugins, save the setup, play through the plugins, change things, save, repeat …
As you mentioned - the first time you create the plugins and save them it’s ok, but it seems that somehow states of these plugins “grow” when you perform certain action on them.
I’ve loaded your file and replacing the plugins with a fresh version of the same plugin immediately releases the memory and saved files results in a miniature gig file.
I’ve noticed that you use VST3 versions exclusively. Have you observed the same behaviour with VST2 versions?
We have a very good relationship with Arturia and we can bring this to their attention, but we need to figure a way to reliably reproduce this problem.
Answers are inside quote!.
Do you have widgets connected to the VSTs that may be changing values of various parameters? I’m thinking the ‘growth’ could be occurring because these values change from the original preset during usage, then you save the gig file again which then causes state to be saved for these given plugins. This is one significant difference I’ve noted between Gig Performer and the host I used previously. Maybe this warrants a behavior option feature request.
I would like a global option that basically forces me to ‘commit’ the state of a rackspace before I move to another one or I ‘lose’ those changes. That way I have to intentionally commit changes rather than possibly ‘accidentally’ create a change simply by moving to the next rackspace.
X
Gig Performer saves whatever state the plugin returns and injects exactly that same state back when the rackspace is reloaded. If that state gets bigger every time, that’s a plugin bug. This issue seems to only be happening for a few Arturia plugins, it’s not happening for the vast majority (read, pretty much every other plugin out there) of plugins.
I haven’t been in my house for a while so couldn’t test the whole thing until today and now I have a more detailed version about what is causing this problem.
First of all and to make clear: Is not a Gig Performer bug. Is an arturia bug.
The thing is that some of the saved preset within the plugin are buggy. I can confirm this by loading those buggy saved preset within the standalone version of those plugins, the original preset only use little RAM but when the saved preset is loaded then the amount of RAM increase a lot.
I cannot confirm what was the origin of those buggy saved presets, maybe when first creating my presets there was a lot of Analog Lab 4 instances around at once and then I saved the preset within that rompler instead of using the standalone plugin, I tried but I cannot replicate the bug so the best I can do is to to send those buggy presets to Arturia.
Sorry for the inconvenience guys, It was hard to isolate the cause at first…your software rocks 
.
Hey, thanks so much for taking the time to both figure out the problem and report back here for he benefit of others.
I also use most of those Arturia plugins.
One thing I noticed early on is that the Mini V (MiniMoog) sucks juice, (around 30-35% CPU load.)
I build a bypass switch into all instances so the plugin is disabled when not directly needed in a rack or variation. (Also ditto Amplitube)
If you set the volume to zero, it is supposed to do the same. For the effects… I don’t know 
It is one suggestion I have made to have a switch “hard-wired” into each rack to bypass all plugins it uses.
It makes a massive difference in some configurations.
I don’t think the volume has any effect, and anyway, I use the gain plugins to control volume, rather than the instrument volume as I have found that even at zero there is a residual sound.
You are right it is not automatic to bypass the plugin when the volume of the gain plugin is zero. It was a scripting trick:
https://gigperformer.com/bypass-plugins-automatically-when-volume-is-off/
I haven’t had experienced high CPU usage with Mini V3. What version of Mini do you use?
I have a Rackspace with 3 Mini V3 at once, and using one active per variation. I create different midis input and I bypass those that I don’t need for a specific variation. Using this strategy I cap at 23% of CPU usage according to GigPerformer.
That looks like a total sledgehammer to crack a nut.
Perhaps, but a very nice sledgehammer 