Issues with long loading times

Hello, I experience unexpected long waiting times when using GP in two situations:

  1. Loading my initial GP file: I created a setlist of 22 songs that each have their own rackspace with a single variation. Each rackspace consists of one to three external VSTs and all have a pretty simple layout. The functional equivalent in a typical DAW like Cubase or Ableton would load in maybe 10 seconds. However in GP I usually wait more than a minute until I can use it. Is this normal behavior? Where does the long processing time come from? How can I speed this up?

  2. When I change the audio options (either switch to another ASIO driver or changing bitrates/buffer sizes) again I usually have to wait about a minute and GP freezes. Sometimes it will become unresponsive and I will have to restart it. You might think this is a driver problem but all the drivers I use and the configurations I choose work flawlessly with other applications. Do other users experience the same phenomenon?

1 Like

Really in a DAW about 66 plugins?

When you change Audio that is normal behavior, because the plugins audio has to be initialized and that depends on the use audio driver and it’s settings.

What applications work this way?

I’ve been using Ableton Live for many years. Changing settings for the Focusrite ASIO driver works almost instantly.

With 66 plugins loaded?

This is more a procedural issue than anything else. It’s never recommended to change bitrates/buffers with full projects loaded, in any circumstance. Either change those things through the ASIO control panel of the audio device (if it has one) with no audio app running, or load a blank gig in GP and change them, then load your main project. You’ll cut way down on crashes that way.

3 Likes

Yes, that is right, I have learned it the hard way (PC, Windows 10).

A few days ago I disconnected my Focusrite Scarlett by mistake and GP4 freezed. After that my GigFile in GP4 started only with Windows Audio, I could not change the Audio Device type , GP4 crashed immediately without warning and without report. It was useless to restart the PC or to restart GP4.

Then I loaded a blank GigFile, but it couldn’t find any ASIO driver, there was no Focusride Asio driver in my PC, the Asio driver was gone. I had to reinstall all Focusride drivers (with the Focusride Console), then I could change the Audio Device type in the blank Gig File and after that I could load my GigFile with 45 rackspaces.

Okay, but other DAWs got this issue under control pretty well. Maybe the implementation of the ASIO driver interface could be improved in this regard?

It’s also a bit of a problem because my system will change behavior all the time, sometimes I can run a complex setup at low latency settings without any problems, sometimes I get heavy noise and dropouts. So I will need to change settings several times. When I close my GP project every time I will have to reload it afterwards which will take about a minute again, so this is not really a feasible workflow. And again, while other applications surely cause issues as well at some point when you mess with the driver settings they got to a point where you can work live with it with an uninterrupted workflow.

GP is not a DAW. Yes, it loads plugins but arguing that that means it’s a DAW is like saying that an automobile is an airplane because you can put people in both of them!

I didn’t quite get to that point because the setup was becoming too complex in Ableton Live (basically my reason for switching to GP) but yes, definitely with dozens of active plugins. The might use a more efficient implementation of the VST and driver interfaces? I’m no expert in this, so I can just speculate.

Is there maybe a way to make my project more efficient? Since all the rackspaces basically only use the same about six different plugins, just with different patches. I just don’t quite see a way to get around the practice of using many instances of the same plugin.

Yes, I know. I still hope my point is clear even without 100% accurate choice of words.

Did you try predictive load?

Your point is clear but your argument for making the point does not really apply.

Here’s the thing - a surprisingly large percentage of plugins, even from well-known companies, do not properly handle reset requests - something that has to be done when you change the sample rate and/or buffer size. In such cases, you can get a crash.

In the DAW scenario, one can mostly live with that because, in the studio, you can just restart everything - you’re not doing a live show - there’s no audience waiting around.

In a live situation, you can’t afford a crash and the only way to ensure this is to reload the plugins.

You’ll note perhaps that if you load GP by itself, it loads pretty instantly. The delays are due to the loading time of plugins and one should perhaps beat up plugin developers to get them to have their plugins load more quickly :slight_smile:

Predictive loading is certainly one option and if you’re following a setlist, you’ll still be able to get the benefits of such things as instantly switching, patch persist, etc.

If you don’t care about those, then you could use the GP Script LoadGPPreset function. We introduced this in GP4 as a new experimental feature, (because we can’t guarantee that every plugin can handle having their state reset (again, an issue for plugin developers) we haven’t actually had any reports of failures and so it seems to be quite reliable.

With this approach, you could have all your plugins in a single rackspace (if your RAM and CPU allow it) and by using the On Variation callback in GP Script you could just have lots of variations and each one could load new presets for each plugin. But you won’t get instant switching and you won’t get patch persist functionality.

Thanks, I’ll try that. For a concert situation (indeed always with predefined setlists) I think this will be a good solution.

I use the same setup with about 40 songs with maybe 5 that share a rackspace, the rest have their own rackspace. And while it takes a minute or so to initially load I’ve never seen that as a problem as it is going to support a four hour show with no glitches. I have plenty of stuff to do before a show to allow my gig file a minute or two to load up.

2 Likes

If this is a thing you only have to do once before a rehearsal or show this is absolutely acceptable for me. But for instance if I have to reconfigure my midi controller I have to shut down GP first and I will have to reload it every time to test my changes. And then it becomes a problem because in my last rehearsal I had to tell the whole band to stand by for like ten minutes only because I needed a control change on my midi controller and I needed two tries to find the right settings.

Why do you have to reconfigure your controller and even if you do, why do you have to do it at a rehearsal rather than before you get to rehearsal?

1 Like

I might have to change what buttons and pads do. This might not happen a lot but it actually did happen once and might happen again. There might also be other things coming up that will require me to restart GP.

I tried it and while it indeed shortens the loading time on startup it will also make GP instable. When I press the next song button a few times too many GP will crash.