Crashing in Gig Performer

Hi,

Typically, I use GP Essentials with 2 instances of Unify2, one for each of my 2 contoller keyboards.  I have seen rare GP crashes but I can't remember what I was doing at the time.

But I tried your "Unify GP Simple Gig Files" GP and then loaded Unify Standard Library patch "STACK - 8 Layers ALIVE" a few times and had no crashes.  What does your specific 8-synth Unify patch consist of?  I didn't try your MPE GPs because I don't have MPE controllers.  

Posted by: @craigr68

↑

What does your specific 8-synth Unify patch consist of? 

Picture attached showing the 8 Synths in Unify.    Other 8-synth files with different sets of synths are crashing too.  I don't know if one or more of the specific synths is problematic to GP at this point.

In any case, the issue seems to be that patches that are working fine with Unify standalone, or Unify plugin inside of Bitwig, are causing crashes with Unify inside of GP.   What is or could be happening at that interface/situation is a level of technical detail that I think only the developers could figure out.

I will also test loading 8 layer synth patches in Unify2 hosted with GP - what I would say is that with hosting 8 third party synths in a Unify patch is this open up many chances that the crash is related to one of those plugins - makes it much harder to diagnose unless I can also get a copy of the Arturia synths in your patch (I will email them to try get a tests copy) - I have all the others.

Since this crash occurs in Unify1 - which has been pretty rock solid and not changed in a long time, it points to not being issue due to recent Unify2 code changes.

Can you re-test with a patch that just hosts 8 layers of Gurusampler (1 or 2) (just take that same patch and replace the third party plugins)?

We had an issue in the recent past with GP causing a crash with an older version of Unify2 due to an incorrect bit of transport logic (which I added a work around for in Unify2) - but that was since resolved in GP (and doesn't affect Unify1) - so I would also recommend to make sure you are on the latest version of GP/Unify2 and any of the hosted plugins. Make sure to have the latest audio interface drivers for your hardware too.

@progster Also please confirm which versions of each of the plugins/hosts you are testing with.

Posted by: @wavesequencer

↑

@progster Also please confirm which versions of each of the plugins/hosts you are testing with.

Diva Rev 16519 VST2
Bazille Rev 16518 VST2
Hive 2 Rev 16520 VST2
SQ80 Version 1.6.5.6366 VST2
CZ V Version 1.9.4.6366 VST2
Jup-8 V4 Version 4.6.4.6366 VST2
Serum 2 Version 1.368 VST2
Pigments Version 7.0.1.6772 VST2

I'll get back to you with further testing resuts as requested.   Thanks again!

Posted by: @wavesequencer

↑

Can you re-test with a patch that just hosts 8 layers of Gurusampler (1 or 2) (just take that same patch and replace the third party plugins)?

You could try a process of elimination.. remove plugins one by one and reload the patch in GP.. see when it stops crashing - then you've identified the plugin. If you can confirm which one, then I can test that specifically.

Although it could be a combination of plugins.

I've noticed whilst debugging that many if not all the UHE plugins have memory leaks when they are unloaded (this is something that gets caught by the debugger when I close Unify2 in a debug session).

Thank you for your reply, and suggestion.

Working by elimination as you suggest, what I observe is that a very simple gig file with all 8 of the MPE synths active in Unify (1) causes GP to crash.

Similar simple gig files that substitute Guru Sampler in at least 1 slot do not (in general) immediately crash.   There does not seem to be a single specific culprit.

FWIW, a .zip file of simple gigs files as described is attached.   (0 = Guru Sampler in that slot)

I just crashed GigPerformer running 2 instances of Unify2 when I tried to copy and paste a Macro knob.  I've seen this occasionally and at times it gets fairly consistent.  I suppose it's unrelated to Progster's crashes.

There is a chance there are still issues with Macro knobs logic when copying/pasting (and those would likely show up in the standalone build too) - I will have to do some more testing on that, but it should be unrelated to loading a project into GP.
However, it would be good to understand if @progster 's multi-plugin Unify2 project includes different plugin macro links, and if those macro LFOs were running with the project was saved.

@progster Thanks for the extra details.
And so you are confirming that Unify1 is also crashing with these 8 MPE plugin instances? What is the MPE controllers you are using?

As mentioned in my previous post - do you have macro links set up with the plugins in the Unify1 or 2 project.

@getdunne - if you get a chance to look at the forum. Any ideas?

Posted by: @wavesequencer

↑

And so you are confirming that Unify1 is also crashing with these 8 MPE plugin instances?

Posted by: @wavesequencer

↑

What is the MPE controllers you are using?

Posted by: @wavesequencer

↑

do you have macro links set up with the plugins in the Unify1 or 2 project.

@wavesequencer

These crashes are probably due to the specific plug-ins in use. Gig Performer has options to get a crash report, from which the GP developers can determine what actually crashed. I'm no longer full-time with Deskew so @progster should contact them directly for support.

Layering up Diva, Bazille, Hive, SQ80, CZ V, Jup-8 V, Serum 2, and Pigments is pretty much a torture-test for any CPU, and may be too much to expect from Windows. All I can suggest is to try a larger buffer size and see if it still fails.

As for why the crashes occur with Unify inside GP, but not Unify stand-alone, it may be that this patch pushes the CPU and OS so hard, that even adding the relatively low overhead of GP pushes it over the edge into failure.

@progster Yes - I was wondering if the macros are linked to any parameters - more specifically a potential issue with Unify2 project recall since I made quite a few changes in the way macros operate in relation to macro LFOs.

I am also wondering if you re-call the same multi-layer Unify patch in any other DAW/Plugin host, does it still crash.

Please let us know the results of any crash log investigation from GP support.

If you run Unify2 you can put it into a special logging mode (in the Windows build) - however it currently requires entering a code on the settings page to activate it -so might not be useful in the case of restoring a GP project where the whole plugin is reloaded.

From Discord FAQ:

https://discord.com/channels/992860977903173682/1549498206696509450/1549498206696509450

In Unify2 Windows version there is a logger/logging mode that can be activated from the settings panel - it doesn't run all the time to avoid overheads, however it's also minimally used (not used in audio rate updates) and will survive an application crash as it launches a separate process (a separate log gathering app/window) to capture the log output (which is sent over IPC using OSC messages):

To start logging: Open the settings page, on the UI settings panel, scroll down to the developer text entry box enter the text: "ShowGuruLogTools" - a checkbox will appear, check it to 'start logging session' - this will launch a background process (a helper app that is installed alongside Unify2) that may require you to approve network access for it and Unify2 (OSC message based - just local to the computer).

It will collect events and will write to a log file even if Unify2 crashes. The log file is written to:C:\Users"your user name"\Documents\PlugInGuru\Unify2\Logs The log captures basic events like plugin loading, layer add events .. it might help us to debug app crashes.

(Currently only available in Windows - there is a Mac version, but it's not ready - there are some issues with launch permissiosn)

@getdunne Thanks for the reply Shane. Yes this is a pretty heavy set of plugins to recall.. high chance one of them is the culprit for the crash, which is why I am trying to get those Arturia ones into my collection.
There is certainly a difference in terms of plugin state recall vs just directly loading a Unify patch - possibly that difference causes an issue with one of the plugins..and I would suspect the same issue would crop up restoring the same Unify state in any other DAW, but perhaps there are differences in things like timing of when the host triggers 'prepare to play' or sets the values of the automation parameters.

@progster - would be also interesting to understand your machine configuration - especially available RAM.

Just FYI I did some tests (Win 11, 10th Gen i9, 32GB RAM) with the latest Unify2 and half a dozen commercial plugins loaded when recalling a GP project, and not seeing any issues.. I am running the very latest GP version - so that's probably something to check also (get the latest GP).

I do notice some odd behavior on the Unify2 elapsed time when hosted in GP (5.1.4) and in 'Host follow when running mode'.. after starting and stopping playback in GP (green play button), the transport state/buttons is in Unify2 is blocked, and the time is jumping between 00 and 02 seconds. Almost like the host (GP) keeps resetting the clock when in stopped mode. 
I'd need to dig into this later, but looks like bad behavior on the part of GP as this is not a problem in other hosts like Ableton. 

So you might want to try with the patch saved in 'Host follow always' mode.

@wavesequencer

GP5 had some goofy transport issues, but they've been fixed in the forthcoming GP6, and as far as I know the fixes were back-ported to GP5. I have GP 5.3.2, and I think there has been at least one release after that.

Thanks for all the commentary!

I've got the log going on a StandAlone Unify 2. I've attached a log, probably not directly relevant to anything at this point, but I did notice this line:

8, 122115, UnifyEditor::badPointerListenerCallback,0, 0.000000

"badPointer" is always a flag for me, but may be normal here.

Is there any way to suppress the 'Keep Alive' messages?

Is there any way to keep the logging on across relaunches of Unify 2?

Attached here is a picture of good ole 'Synth 8 MPE A' loaded in Standalone Unify 2, along with Resource Monitor - Memory.

As can be seen, I believe, 'Synth 8 MPE A' alone is not stressing my Available memory.   It's a 32 GB machine. 

Is there more system detail that I should post?

Now, in more complex contexts, yes, that Available can get small or get all used up - however, just want to set aside any notion that the 8 plugins themselves are taking over all my memory.   Not even close.

I just did a test inside of GP (v5.3.3, the latest) -

Put Unify 2 inside the default Wiring Diagram.   Turned on logging.

Attempted load of  'Synth 8 MPE A' .     GP immediately crashed.

I don't see anything in the log (attached) except for the repetitive messages.

Posted by: @getdunne

↑

it may be that this patch pushes the CPU and OS so hard, that even adding the relatively low overhead of GP pushes it over the edge into failure.

Posted by: @wavesequencer

↑

I am also wondering if you re-call the same multi-layer Unify patch in any other DAW/Plugin host, does it still crash.

Tested this AM with Unify 1 in Live.   Loads and plays, neither Live nor Unify crashes.   (pic attached)

Tested this AM with Unify 1 in Reaper. Loads and plays, neither Reaper nor Unify crashes. (pic attached)

Tested this AM with Unify 2 in Studio One Pro. Loads and plays, neither S1 nor Unify crashes. (pic attached)

And inside of S1 I sequentially loaded  'Synth 8 MPE A', 'Synth 8 MPE C', 'Synth 8 MPE A' and produced a log (attached), which looks OK to me.

And yes, this AM I still get the same crash(es) when using GP - so that's not a freak behavior based on the day!

@progster 'badPointerListenerCallback' is a normal message in Unify code base.. it's a signal to tell the UI that layers or other things are getting deleted (and so then make sure not to use them). Bit of a strange name, but that's the legacy code 🙂

The ping message probably doesn't need to be in the log.. it was there originally for me to confirm that Unify2 is indeed correctly communicating with the logger app - can probably be suppressed in a future version.

For the moment there's no way to auto-restart the logging - I would need to make some code changes to have it look out for a file/user setting on the disk - and it's designed to make sure the log file gets written to the disk if the ping messages stop arriving, so the logger (receiver process) is designed to auto-shutdown to make that happen, but it could be re-started automatically if that is a setting Unify2 can read on startup.

@progster Interesting to see the log from the GP crash - there is no log entry showing even a single attempted plugin load, so it looks like something is happening just before or at state recall before a plugin is loaded.

Can you confirm if you are loading the 8 layer patch from within Unify2 (hosted in GP), or is it recall of a GP project? (because if you are recalling a GP preset/project then it's probably unloading Unify2 and stopping the logging).

Seems like a GP specific issue for sure - did they comment on it?

I don't have those Arturia plugins yet so can't test this specific patch setup, but have not had issues with my slightly older install of GP I tested with with Unify2 multiple plugin projects.

I tested with GP 5.3.3 and no issues loading a complex multi-plugin Unify2 project again on same Win 11 machine.
Also note that with the 5.3.3 version the transport issue I mentioned before is resolved.

Posted by: @wavesequencer

↑

loading the 8 layer patch from within Unify2 (hosted in GP),

Posted by: @wavesequencer

↑

Seems like a GP specific issue for sure - did they comment on it?

Posted by: @wavesequencer

↑

I don't have those Arturia plugins yet

Posted by: @wavesequencer

↑

Also note that with the 5.3.3 version the transport issue I mentioned before is resolved.

Arturia has Pigments Play which is like a trial.  That's how I got hooked and wound up buying Pigments.

Another data point -  using 8 instances of Pigments VST (only) in Unify 2 will create the crash in GP. 

It seems the U-he plugs are in-the-clear, at least as far as being personally responsible!

Progster

I was able to open your patch in GP.  I can't get it to crash GP.  Tried about 10 times.  It plays ok although it kind of pegs GP, on verge of glitching, at times climbing to 85%.  In your patch, the MIDI-Channel-Filter plugin came up red.  I replaced it with pizmidi midiChannelFilter plugin.  Slight name difference for some reason.  Don't know what it's supposed to do.  I attached a screenshot.

My computer is i7-8750H 2.20 GHz, 32G mem, Nvidia Gforce 1060, 1.5T SSD, about 7 years old, Alienware M15 gaming laptop.

Running GP Essentials Ver 5.3.3 which I had recently updated to.

Posted by: @craigr68

↑

I was able to open your patch in GP.  I can't get it to crash GP.

Here is a video showing the reproducible crash here:

https://youtu.be/94HmjXUejDw

Tried the same experiment with Serum2 x8  (instead of Pigments x8).   GP did not crash.

How about using Pigments vst3 instead of vst2?  I took your layer 8, multiplied it 7 more times for a total of 15 layers, and still no crashes.  Maybe Arturia would look into it.  They seemed quite responsive to a recent ticket I had with them.

Posted by: @craigr68

↑

How about using Pigments vst3 instead of vst2? 

BTW, I wrote to Arturia today  - so too early for their response.

I also updated the 8 layer MPE patch shared here to become 16 layers of Pigments (modified to the VST3 version since I don't install VST2 these days for compatibility reasons).
I can save and load it when Unify2 is hosted within GP without any issues.

I can also save the whole GP state, reset to an empty rackspace, then re-load the old project with Unify2 / 16 layers of Pigments.

Again this is on my Win11 machine with a 10th Gen i9 and 32 Gigs of RAM.. and I am in the middle of coding with multiple instances of Visual studio projects also open. 

This makes me wonder if maybe you have a system specific issue on your machine @progster - although strange it's only happening in GP and not other DAWs. Could be potentially something to do with thread allocation maybe.. or GP panics if a plugin takes too long to restore state (except looking at the video, looks like it didn't even get to try loading a plugin before Unify2 crashed).

@wavesequencer  Very interesting.  Thanks very much for running this test.  

If there is any chance of you posting the x16 patch and the .gig file, I would like to try them at my end.

Thanks again!

Attached (note I did remove those MIDI plugins that I don't have on my system)