I’m wondering why my gigfile use so much RAM in each song and rackspace.
Also I think that this is the primary cause for long loading times when changing between songs on a setlist or rackspaces.
For example in one song I use the following plugins distributed on 5 rackspace with variations in some of them (through my setlist I use only Arturia V-Collections 7 plugins):
Instances | Plugin
1 Jup-8
2 Vox Continental
4 DX7
1 Mini
1 Prophet
1 Solina
1 Mellotron
1 CS-80 Total plugins used in one song: 12
When I load the setlist I notice the following:
1.- The song is loaded with 9GB of RAM using above plugins at first.
2.- Waiting for some amount of time (maybe 3 minutes) on that song results in a decreased amount of RAM (doing nothing) that results in 4GB loaded.
3.- Loading the same set of plugins (12) in a Cubase 9 on PC B (specs below) gives me 1.5GB but 20% of CPU usage (ready to trigger plugins).
4.- CPU usage on GigPerformer is about 5% on this song, which is desired because of rackspace model.
5.- Gig Performer takes more than 4 minutes to load a new song (using jumping method) using PC A. Comparatively Cubase 9 only load those 12 plugins on 40 about segs using PC B. The same is true when loading rackspace and even with predictive loading, 3 max rackspace.
Also I noted that loading a rackspace with predictive loading and max rackspace of 3 gives me about 10 GB (not in setlist mode), in some of rackspaces, when using a subset number of that plugins (think about of 7 plugins). Which is strange.
Loading rackspaces or songs involve some peaks of RAM, that sometimes surpase RAM usage and therefore GP crash. Is freeing memory first then loading?
I think that this scenario is not expected when using Gig Performer so there is something wrong here. This “problem” is not new in my environment, I was able to do some rackspace efficiency-related work using variations in order to free some RAM, but it was not enough, I know that there is some thing hidden that impacts my gigfile.
This is a little strange. How many rackspaces is that song using? You say that total number of plugins used in a SONG is 12, but if you use 10 rackspaces with 12 plugins each - you are loading 120 plugins, not 12.
If it takes 4 minutes to load 12 plugins - either those plugins require huge amounts of ram and are loading a lot of samples or your hard disk is really slow.
Comparing computers A and B is also very ambiguous. While PC A is i7 - it is also running at more than 30% slower clock speeds. There is no mention of hard disk types used, weather samples are on the main drive or some external USB drive, what kind of memory is each computer using, bus … The list goes on.
Ok - I’ve never heard of 12 plugins loading for more than 4 minutes. There must be something that’s holding things up. Also - I assume this is a gig file that is saved and loaded in v 3.5 of GP right?
Could you make sure that network is completely disabled when you are loading the gig file.
It is possible that a plugin is trying to do something over the network.
I just tested on Mac (on this machine I do not have available most of the used plugins).
I started Gig performer, predictive load unchecked.
I loaded in Rackspace Mode, it took about 5 Minutes to load.
Then I loaded again, about 1 Minute.
Then I restarted Gig performer, loaded again, about 1 Minute.
I am wondering, if some cache mechanism is forcing the faster load.
@djogon I disabled networks completely and tested but it change nothing.
@pianopaul thanks for your test. Most of the plugins that I used in the gigfile are the original plugins from Arturia (namely Jup-8, Vox Continental, DX7, etc), maybe there about 3 Analog Lab 4 instances in all the setlist. I did that change thinking the same way as you, that Analog Lab 4 takes more memory but It has not proved real impact.
Still worries me RAM usage, maybe is the principal symptom? Why those plugins are using so much RAM but when using in a DAW environment they are pretty light. Is there a possibility that my gigfile became corrupted in some way?
Yes I’m trying that and I see strange things in terms of size of some rackspace. Then I changes the anomalies rackspaces with new ones and it seems to work.
I’m going to upload my results when I have finsished to rebuilding my gig file.
I agree that the RAM usage is odd. I believe that all the Arturia plugins are physical models and to not use much RAM.
My main rack file uses 7 Arturia plugins. I just tested GP and found the following:
GP with no backspaces loaded uses 345 MB of memory,
GP with just the 7 Arturia plugins loaded uses 1.91 GB of memory
I’m using GP on a Mac but my Windows backup laptop shows much the same. The Arturia plugins I’m loading are Clavinet, Farfisa, Vox, Piano V2, Oberheim SEM, Modular V and Mellotron, all the latest versions.
If your results are a lot different you might want to reach out to Arturia for help. I’ve found their support to be slow but thorough and detailed.
Hi Ezra,
definitely there is something wrong in how my gigfile was built.
I have a grasp about what is causing that, but not the exact details, for this I’m going to realese at night my results.
I loaded this gig file in a computer where I have no plugin installed, and it drastically slows down 3 to 4 times during loading and always at the same rackspaces. Thoses rackspaces don’t seem to be very complicated, they don’t contain any script and each time the loading slows drastically down, the processor load rise to 100% on one core.
Yes those are malformed rackspace and there are about 4 in the setlist. I judge them malformed only because of filesize.
I’m going to upload 2 of them: one malformed and another recreated, in order to see the difference which I can’t see with a text editor. malformed (2.9 MB) good (16.2 KB)
