I guess this blog article could be useful anywhere where people report problems with a plugin and try to determine why their audio plugin host crashed.
They could download a trial version of Gig Performer, re-create their setup from another application and then use this technique to find a problem…
If Mainstage, Cantabile, etc. users suspect that a plugin is causing problems, but can’t figure out which one – they can follow this procedure and troubleshoot problems with Gig Performer.
Just starting to try out Gig Performer, but in all other hosts there’s a much easier way then trial and error (disabling suspect plugins). At least on PC. Usually when a plug in crashes, even if it’s in another host, the windows event viewer will record that event. If your host crashes, just go to the event viewer. There will be some entry like ‘myPlugin.dll.’ crashed.
This is also the case with Gig Performer which produces a detailed crash report, but sometimes some plugins crash Windows in such a deep way that the autopsy is not possible. The the trick given by @npudar becomes very interesting.
But I hope you don’t start with GP by having trouble?
I certainly hope not :). I purchased it today without much testing just becasue of of the PA sale (and I had a voucher on top of that). I wanted to evaluate becasue I’m also due to pay an upgrade fee to stay with Cantabile (need to update to get vst3 support), which would be twice as much (and which I still have to pay in case GP3 doesn’t work out for me).
I did test GP a couple years ago when Forte ceased development and it wasn’t quite there yet in terms of stability and features. I wanted to give it another shot since PA picked it up and I really never had any issues with any software I purchased through them.
I had quite a journey so far. Cantabile 2 > Forte > Cantabile 3 > Possibly GP3
Overall, I’m trying to simplify my setup. In the past I used a huge variety of plugins between the entire set list (I’m in a Cars tribute band). Mostly synth, only small samples via Tal Sampler here and there. To make song changes quick, I basically had to load everything into memory in Forte or Cantabile (pre-load setlist). When I tried the same approach in GP, the memory went through the roof and it just kept crashing.
I experimented a lot with Roland Zenology lately, and I think it’s at a point where I can get away with using that (between 4-5 different instances at a time) for the most part. The 10% of sounds it can’t handle, I’ll just sample from other plugins. Although, Rolands online activation that’s needed every 7 days makes me a bit nervous to rely on it live…
Yeah, the predictive loading works fine. I which there would be an option to bypass processing for plugins. I.e. load them but bypass them until you actually select that song.
The Zenology is requires a lot of processing even if it doesn’t play. So if you have two songs next to each other that have a bunch of instances of Zenology, it does drain CPU a lot. I can work around by inserting a ‘blank’ song in between.
when predictive load is not enabled bad programmed plugins consume CPU
And when predictive load is enabled and a rackspace is marked in green, the plugins contained in that rackspace consume CPU even when not played.
IK Multimedia Hammond consumes CPU, even when not played.
It does seem to be an issue with Zenology for the most part. Every instance adds about 10% to the CPU load just by being there. Unfortunately the 3 songs that use the most instances are also next to each other in the set list. So by the time I get to the 2nd song, I get dropouts like crazy. If I spread them out between less CPU intensive songs, they work just fine. I think this is where Cantabile worked different. When pre-loading a set list, it would load every plug-in instances that were shared between the different racks (using ‘linked racks’) into memory creating a high memory load, but the processing was disabled except the ones in the active song.
I’ll look into scripting. For the time being, I’ll just insert a blank rackspace in between the songs. The loading time between them is fine, so that will work for now.
Another good solution would be if I could disable keeping the previous rack in memory. The way I have the controls mapped, I can only move forward when I push a button the controller, not back anyways. So the way I work, there’s little value in keeping that song in memory.
Just to clarify — poorly behaved plugins that are running code even when there’s no audio to be processed. A well behaved plugin should disable all unnecessary activity when there is no audio to be processed. Unfortunately some developers don’t think about this and spawn off lots of threads, timers and even GUI stuff that runs when the plugin editor isn’t even open.
Tip: watch out where you store plugin related files. From this YouTube video:
Everything is cloud based now and some of these plugin companies have not caught up to the fact that your Documents folder might have references to files and not the actual files inside it. So my iCloud documents folder on my Mac, for example, Positive Grid plugins from Bias for the longest time, they stored all of their setup configuration in your documents folder. Well, the Mac doesn’t know that and it would just decide - Oh, you haven’t used that plugin in 30 days, you must not be using those documents and we’ll upload them to the cloud - and they are gone. And every time I open the Bias amp, they crash the computer. Every single time.
