I’m currently building a gig of 38 rackspace until now mostly using Arturia Analog Lab 4 instances. While building I notice an ever increase of load time of the gig. Right now is extremely slow, and it takes about 5 - 8 mins of load (using predictive loading with 3 max rackspace). I also notice that the .gig file size is about 1.35 GB of space which I think is lot, and the direct cause of this. Is this normal behaviour? I don’t think so because DAW file size using lot of plugins never reach that amount of space. So what I’m doing wrong?. Currenty the file is the 4 copy a new save copy from a older version. i.e gigexample(4).gig
As a side note every rackspace never use more than 3 Analog Lab instances.
Gig file size and load times completely depend on the plugins you use and how they store/restore the information.
If you are using 3 Analog Lab instances per your 38 rackspaces - you are loading 114 of those plugins. If each plugin wants to use about 10Mb of space to save its state - you are at the 1Gb mark approximately.
1,35Gb is actually not that big at all. Many users use much larger gig files.
Which DAW? How many plugins? Are you sure you inserted 114 Analog Labs into a DAW and saved the file, then looked at the size?
Load times also depend on the plugin’s ability to restore its state, BUT if you say that you are using predictive loading set to 3 and it takes 5 minutes to load the gig file - there’s something else wrong.
Could you please enable predictive loading and set it to 3, then measure exactly how long it takes to load your gig and let us know. Thanks.
I also became dismayed to see my gig file increase load time (minutes?) as I built a 15 song list. I probably have total of 10+ instances of Arturia Analog Lab 4 VST3 in the various rackspaces. So I wonder if Analog Lab 4 is causing the long load time. (It does become stressful knowing a shutdown and relaunch of GP will probably be longer than an average song. I have a very powerful pcAudioLabs computer with Solid State drives so at least that reboots very fast.)
Remove all instances of Analog Lab4 from your rackspaces
Save your gig as a new gig file
Load and compare the load times.
I am interested to get more information about the claims from @progloverfan where he states that “predictive loading is set to 3” and the loading time is still 5-8 minutes for those 38 rackspaces.
Is it possible that your computer is connected to a network, but there is no internet connection?
Many plugins will try to “ungracefully” connect to the internet if there is a network connection. If the DNS is not reachable because you are not connected to the internet - the computer will stall for a LONG time until it times out.
Then it will do this again, and again …
Please try to unplug any network cables, disable the WiFi on that machine and then try to load.
The 1.5Gb size is really a big nothing, but this network issue may explain things.
Thank you for the video. The (2) gig which loads fast still has 26 rackspaces so it’s not the number of rackspaces that matters. What does matter is actually loading and parsing a very large file. Once loaded and parsed - things go quickly. Also loading rackspaces later is also fast because everything else is pre loaded.
I wonder what is actually taking so much space for just 30 rackspaces.
Is there a chance you could zip and send me that (3) gig file? It should compress well and you can use some sort of cloud based service.
Send me a private message through these forums with a link if you don’t want to post it here.
I’ll then take a look and identify what is taking so much space in your gig files.
Thanks @progloverfan I got the file. Here are some results
Tried opening it as a text file with one text editor - I had to give up after 10 minutes or so. It was still loading it.
Tried with another - reported OSX out of memory (I have 16gb of ram)
Tried with a third one which opened it somehow.
I determined that the space is used by Analog Lab 4 states. You have about 2 of these in each rackspace and this plugin seems to have a huge state.
Opening your file on Windows took about 3-4 minutes to load/parse the file and another 30sec - 60sec to actually open the file which is consistent with your findings of 5min.
Opening your file on my Mac in GP took about 15sec to open/parse the file and around 30sec to load everything.
There seems to be a huge difference in how OSX and Windows handle this, but I can happily say that GP handles it really, really well. Text editors had trouble opening it at all while we opened it on a Mac in 30sec.
Unfortunately - there is really nothing that can be done here to improve things on GP side.
I would suggest that you write to Arturia and ask them to see if the state management can be improved and size reduced. They are actually quite good with listening to user suggestions.
Having said all this - we think we can still improve GP a lot by introducing some clever handling.
Let us see what we can do to improve the situation on our end.
Does Analog Lab basically load ALL the included synths in some sense? I noticed a cpu hit in racks with Analog Lab and when I replaced with just the individual synth it opens to the cpu went way down.
Seems to me it doesn’t make much sense to use Analog Lab really unless you ARE using it to change patches, actually an easy an easy way to have a bunch of different synth choices at your fingertips. Or of course unless you are using Analog Lab standalone without V-Collection
As discussed previously ad nauseum, the way I perform live doesn’t not make it practical to use rack spaces for program changes, despite the benefits of doing it that way for many, I guess.
@pianopaul I’m not sure what would constitute “stress” and it is not causing me any problems at all… I was just curious. I am on Windows and Analog Lab definitely causes higher cpu for me than one of the synths from Analog Lab in its own
Just had an idea about 