[blog] How to find out which plugin crashed Gig Performer

[npudar]

A plugin crashed Gig Performer - how to find out which one - Gig Performer®

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 users of other plugin hosts 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.

–

---

Other tips found across the community

---

[1] Wrap it! With jBridge or Blue Cat’s Patchwork.

[2] Watch out where you store plugin related files → LINK

[3] Installation of one plugin can cause other plugins to crash. → LINK

[4] If you use the VST3 version of H-Reverb it DOES expose the reverb time to the host! → LINK

[5] How to attach the crash log (Windows) → LINK

[6] How to attch the crash log (macOS) → LINK

[7] Activity Monitor Sample Dump → LINK

[8] Some plugins crash on very low buffer sizes → Tonex

[9] Bluetooth driver crash → LINK

[10] - Plugin issue with a specific CPU architecture (in this example, Intel Mac) → LINK

[11] APIs and plugin developer assumptions → LINK

[larsalt]

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.

[David-san]

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?

[larsalt]

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.

[David-san]

@larsalt

in case GP3 doesn’t work out for me

I would be very surprised if GP wouldn’t work for you

[npudar]

@larsalt
There are many happy ex-Forte users here, e.g. :

Introducing myself: Starting my journey with Gig Performer

Hi, finally, I’m a happy new registered user of Gig Performer now, after being on stage with Brainspawn Forte for the last 17 years. Although Forte still runs extremely well on my 7 years old Dell Precision M4800 laptop under Win7, it’s time for a switch to my new Clevo PB51DDS laptop under Win10. Currently I’m taking my time during the lockdown to crossmorph all my sounds from the old Forte laptop to the new one with Gig Performer. I’m playing keyboards in a semi-pro rock and metal cover ban…

He also conducted a little research:

Some research on latency, jitter and buffer size

Hello, tl,dr: Gig Performer offers sufficient low latency and negligible jitter at a buffer size of 128 samples. Full story here: http://www.powerlord.de/site/angel/LatencyTestReport2021.pdf I have been messing around with this topic for some time, and now I finally did it: Measuring the MIDI-to-audio real-world latency and timing jitter depending on the buffer size, comparing Gig Performer and Brainspawn Forte, my old host used for over 15 years. Latency and minimizing it is one of the mo…

So you did a right decision and are on the right place!
Welcome!

[larsalt]

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…

[npudar]

Did you try the Predictive Loading feature?

How to use the Predictive Loading feature and save RAM

–

Crash: multiple versions of the same library used by different plugins. Happened after a plugin update.

@dhj

The crash is due to a file called libpianoprocessor.dylib and there are multiple versions of that file, all with different sizes (sigh)

(source)

[larsalt]

I will tonight, once I’m done with work

[larsalt]

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.

But I’m half way through the set list, and so far it’s been working well!
https://www.facebook.com/photo?fbid=128866612583403&set=a.127361159400615

[pianopaul]

You can bypass a plugin when the rackspace is deactivated and unbypass when activated with a little script.

[larsalt]

Thanks! I have to look into scripting. Today was my first day on GP.

[David-san]

@larsalt

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.

All the plugins in a Rackspace which is not currently active doesn’t make use of the CPU.

[pianopaul]

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.

[larsalt]

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.

[dhj]

@pianopaul

plugins contained in that rackspace consume CPU even when not played.

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.

[pianopaul]

You are absolutely right, I forgot to say “bad programmed plugins contained in that rackspace consume CPU even when not played”

[npudar]

Sonic Cat has updated Purity, the workstation and PCM Sound Module / ROMpler software, to version 1.4.

Changes:

• HiRes/HiDPI/Retina display support (Setup: Zoom 100~300%).
• New Black theme skin (Setup: Skin).
• Sequencer: step note change by drag.
• Possible note hanging fixed on program change event.
• MacOS: AudioUnit: some parameters and program name not restored on total-recall.
• MacOS: AudioUnit: crash fixed with Gig Performer.

Way to go for the last bullet point!

–

Arturia updated their VST3 plugin FX so now it doesn’t crash the host → LINK

[npudar]

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.

(watch the video to learn more)

–

Another issue with iCloud (preset are stored there) and plugin crashing → B-3X iLok warning - #22 by Dave_bass5

[npudar]

Martinic Updates Scanner Vibrato FX Plugin

One of the items from the changelog:

• Fixed VST2 default bus layout in Gig Performer.

(source)

–

SoundToys SpaceBlender - latest update fixes high CPU issue → LINK