First off, I know these are experimental builds and occasional crashes are normal, even expected. But I have been very impressed with the stability of these builds, up through 3091. I wanted to share this to see if others are experiencing similar issues. But since these ARE experimental builds, I am fine moving this discussion elsewhere if asked to do so.
My scenario: With the new Song and Rack Management changes, I have started to recreate my v2 setup, with about 50 racks containing a total of about 110 plugin instances. With the introduction of Embedded Racks, I decided to convert those racks that were specific song to a single into Embedded Racks. And that is when the app started crashing. Loading a song on app startup would likely (but not always) result in an app crash, as would switching from one song to another. After a day of frustration, I switched the Racks back to regular (Shared?) racks, but the app crashes continued. I also noticed that (only on a couple of songs) I was unable to save the Song with the apps converted back to Shared Racks. It was as if the application did not recognize that the Song had changed. (I got around this by doing a Save As… on the song, forcing an overwrite of the existing Song file.)
I have just now reinstalled build 3091, and it seems much more stable. It’s still early in my testing, but I have had no app crashes since.
Replying to my own post: I am experiencing crashes in multiple builds, even the ones that I thought were more stable. I am thinking the problem is more with my laptop (MS Surface Pro 3) and plugins. Something as simple as adding a Rack, adding a Plugin (VB3, for example), and selecting a preset can cause a crash.
So unless others are seeing similar issues, you can disregard my post until I can narrow down my problem better.
EDIT: Like another user mentioned several days ago, I am suspecting the 64-bit version of GSi VB3 to be a big part of my problems. For now, I am using the 32-bit version (with jBridge) and it seems to be stable. Carry on and feel free to ignore my ramblings!
I can confirm strong instability issues with vb3 x64. In my case even simply loading 2 instances of vb3 leads to a crash in 90% of the cases. I’m also on vb3 & jbridge and can report this is behaving stable so far.
Thanks for reporting this. The big question is whether it something about the way Cantabile is hosting vb3 that’s causing the problem, or just an instability in vb3 itself.
Quick question: are you running in aggressive or compatible multi-processor mode and does changing to compatible help?
just curious if this could be the solution so unpacked laptop again and gave it a try. At first glance compatible mode seemed to do the trick: 4 instances if vb3 x64 were running in parallel.
But then again several crashes out if the sudden. So: sorry but this seems to be related to vb3 x64 (maybe a hot release or the like…).
@Roland_Robertson, are you running multiple instances of VB3, or just the one?
Also, are you running the latest version of VB3? I just downloaded the latest (1.4) and have been running some tests here with up to 4 instances in Cantabile 3093 and haven’t had any crashes. Is there something specific that seems to trigger it? I tried with multiple states, switching states while playing MIDI file at it, switching songs, pre-load on and off, in a rack and in a song… no problems.
I am running multiple instances, but no more than 2 or 3. Note that my problems seem to be with the 64-bit version of vb3. The 32-bit version seems to be stable.
EDIT: Yes I have the latest version (at least the latest publicly available version)
If someone would like to put together a song file than demonstrates the problem, I’ll have a closer look, but at the moment I simply can’t reproduce it.
Also when it’s crashing, is it prompting to send a crash report? If so, please send it.
No crash report typically indicates either a stack overflow or a corrupted heap type problem - something where Windows deems the process beyond help and doesn’t even let the exception handling routines to run, and just kills the process.
A google search for “vb3 x64 crash” seems to bring up quite a few reports of issues with this plugin.
I’m curious as to why a user would run multiple instances of VB3 in the same song- switching to different drawbar settings for different parts of the song? By the way, never have had any problems using the J-bridged 32 bit version- but I don’t run multiple instances either.
Not so much in the same song. I have 2 different racks that are used in different songs (and I realize there are ways to make that happen with only one plugin instance, but was trying to keep the songs and racks isolated to allow me to learn the v3 UI).
But as of late (as humphrey mentioned), just loading the x64 plugin into a rack (with no other plugins loaded) caused an immediate crash. After a fresh reboot, things are slightly better, meaning it lasts a little longer until something like changing songs or switching plugins causes a crash.
forgive my ignorance, but if I preload a set list, then every song where VB3 is used would be considered an instance, wouldn’t it? In that case I am definitely using multiple instances of the plug-in and haven’t encountered any problems.
The important factor here is not how many are loaded, but how many are running at once. If you have multiple instances loaded, but only one in the active song then the others aren’t being processed and therefore no concurrent processing as far as the plugin is concerned.
That said, it doesn’t appear that concurrent (aggressive multi-core) is the reason for these issues anyway.
