Crashing in Gig Performer

How about try:

1. From blank GP wiring diagram, create 8 or more Pigments instances without involving Unify

2. From blank GP wiring diagram, create 8 instances or more of Unify each with one instance of Pigments

After creating one instance, you can copy paste to add more.

Posted by: @wavesequencer

↑

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

Thanks!

More interesting data, though I don't know what to make of it -  

Your .gig file crashed GP the first time I tried to load it.   I tried two more times and it loaded!

Building my own .gig file using your Unify patch also worked - did not crash during building, and reloaded OK later.

At this link are more results and files (.unify and .gog).

https://community.gigperformer.com/t/gp-5-3-3-crash-while-opening-rackspace/28031/73

Here is a document showing Copilot response to "What could cause Gig Performer to crash when loading Unify when other hosts do not?".

How much of this is true and correct background vs. how much is just made up junk I cannot evaluate, as I have not personally coded either plugins or plugin hosts.   However, there is enough being said here that IF true, puts me in awe of how any of this stuff ever works at all!

Possibly whatever is true in this doc can suggest to developers what is really going on.

I managed to fire up my prior retired machine. On this machine (Quasar) there is GP 5.0.9, and of course a set of plugins. Interestingly (to me anyway!) I’m not observing crashes on my old machine. IOW, I can load the same .gig or .unify files that crash on my current machine and they load without observed problems.

Here is the situation on the two machines:

Snag_4f19251113×449 45.7 KB

Of note are the four Arturia plugins which have been updated (as has GP).

Further isolation testing will take time, so I may not have immediate results of that to post right away.

Here is a log of isolation testing. Most striking to me is the inconsistency of how many of these crashed on reload the first time and then did not crash on reload the 2nd time. I don’t know what to make of that. These tests were with GP 5.3.3 on the latest machine.

Snag_992e5b888×592 73.1 KB

Subsequently I tried all of the .gig files from this post created above in Gp 5.0.9 on the older machine and they all opened there with no crashes.

The AI output is mostly to be taken with a huge pinch of salt - it's mostly guess-work.

Seems clear there is a difference with your machines/GP version/plugin versions, and others have tested these multi-layered 3rd party plugin patches without issues myself included (although I've not had any response from Arturia on my request to get hold of those V-collection plugins for testing).

You could try GP 5.3.3 on the older machine, and we can potentially then isolate this to the Arturia plugins (and eliminate GP version as the issue) - or.. it's your newer machine that has an issue either OS or maybe even RAM/CPU.

Did you share Windows crash logs with the folks at GP? Do they have any comment on that? 

Another potential test is to use a different plugin host within GP loaded with multiple Arturia plugins.. PluginBuddy is free (although it only hosts 1 plugin at a time) - Kushview Element is another free one.. there are a few others.

If you can reproduce these crashes with a Unify2 project with just one plugin loaded that would also be a useful data point. 

Thanks for your reply!

FWIW -  The old machine is Win 10 Pro.   The new machine is Win 11 Pro.   Both have 32 GB of physical memory.

I have shared various crash logs in this thread:  https://community.gigperformer.com/t/gp-5-3-3-crash-while-opening-rackspace/28031/77

but silence is the typical response.

I hesitate to change GP version on the old machine at this point, maybe at a future point.  Also the old machine cannot be updated to Win 11, so even if Gp 5.3.3 worked on the old machine, that wouldn't really settle the issue.  Both Win 11 itself, and the new Microsoft MIDI system are also part of the entire mix of variables.  

Bottom line I think is that this needs be somehow solved under Win 11 with GP 5.3.3 (or later).

Here is a .gig file built today from scratch in Unify2 inside of GP.   It contains all 8 original synths and the other plugins.

I have observed this file to crash on loading in GP 5.3.3 (new machine, Win 11), and I have observed this file to load without crashing.

Same file, different behaviors.  (?)

Posted by: @wavesequencer

↑

If you can reproduce these crashes with a Unify2 project with just one plugin loaded that would also be a useful data point. 

@Wavesequencer Perhaps this will be useful - attached is a file with 8 patches built in Unify, where each patch has just a single synth plugin (from the established investigative list) along with 7 layers of Guru Sampler, and all the surrounding helper plugs (incl. Shane's).

If I open GP to the default rackspace and then put Unify 2 in the wiring diagram, and then start to load these into it in turn, at some point a crash will be generated.

My hope is that this is quickly reproducible for others than me.

In Unify I created two different patches - one with all U-he synths, and one with all Arturia synths.

In GP, I added Unify to the wiring diagram.and attempted loading of each.

The patch with all U-he synths loaded fine, and the patch with all Arturia synths crashed.

Attached is a video (35 seconds, no sound).

Attempted loading of the same patches in Unify2 gave the exact same results.

In this .zip are the two .unify files.

To most closely (or exactly) reproduce my setup, the MIDI-CHANNEL-FILTER is found here:

https://github.com/getdunne/midi-effects/releases

A breakthrough this morning, from Dadi in the GP Forum.

https://community.gigperformer.com/t/gp-5-3-3-crash-while-opening-rackspace/28031/79

Operational summary is that removing 0 length files from the  C:\ProgramData\Arturia\Presets\Jup-8000 V\User\JP-8080 Patch Bank P1A

path made the GP crashes go away (in my observations so far).

Interestingly (to me), the Jup-8000 itself was not on any of the Unify layers in any of the testing I've reported.

Why Unify and Unify2 (and other DAW hosts) are themselves tolerant of whatever is happening in the Arturia space, and GP is not, I do not know.

Maybe Paul or Shane can comment about how error conditions in sub-levels propagate or do not to cause crashes (or not).

@progster This is a tricky question.. Unify2 cannot be directly trying to to read those files (since it only loads saved plugin states), and it's odd since you didn't have that related plugin loaded in the patch, but there is probably some common Arturia code that scans all the folders within that plugin collection (and maybe it's referenced in the saved plugin state that gets bundled into the Unify2 save state data).. regardless of which plugin is launched - it's somehow causing an exception/race condition only seen when Unify2 is hosted in GP - maybe it's some specific memory corruption or thread initialization error that only comes up in that specific scenario with those 0 length files - or maybe your combination of OS and the Arturia plugins code had a problem with those files (as it doesn't appear to happen in other peoples systems), but it seems to be an Arturia code triggered bug.
Are those files present if you re-install the Arturia preset libraries from scratch? (maybe was a bad download or interrupted installation)

After some further investigation, I believe the directory of User patches in question came from a time some years back when I was working with a non-Arturia JP-8000 editor software along with my JP-8000 hardware.

Correct files saved from that do actually open fine in Arturia's Jup-8000 V, but it seems I saved a couple of 0 length files by accident in

C:\ProgramData\Arturia\Presets\Jup-8000 V\User\JP-8080 Patch Bank P1A

It's not too surprising that encountering a 0 length file causes an issue if that possibility was not considered and explicitly dealt with in advance by Arturia.

And of course, since Arturia would not be deliberately distributing a 0 length file, it is understandable how that case might not have been considered. 😉

Of interest is that these crashes took place without the Jup-8000 V being present in any of the Unify Layers.

I speculate that something about Arturia plugin startup is doing a scan or accessing results of a previous scan wherein the presence of a 0 length file reference is a show-stopper. 

Arturia should be able to reproduce the issue and advise us, now that we've caught the wild goose!