I wanted to try out the new Rack Save State options in the latest experimental build. (I am curious about these features.)
I messed around with some of the Locked states settings in a setlist that I have programmed for an upcoming show.
I went to change songs and… CRASH! ok, no problem. Try loading it up again. Crash again. Tried disabling audio engine. Still crashes.
So I reinstalled the latest stable build. Same crashes! I still haven’t made a lot of states for my racks so I tried removing them in case this was causing the conflict between the 2 versions of cantabile. still crashes. Sometimes with horrible digital audio distortion. Weird hanging artifacts of one of the running plugins also occurs when It crashes.
I can load the setlist with the audio engine disabled and switch between songs without crashes. but as soon as I enable the engine it crashes right away upon selecting a new song.
How do I get my Setlist back and running stable for my upcoming show?
Making progress,
Figured out (through trial and error) that the Rack Running VB3 is causing the problem. When I disable all the instances of VB3 in all the songs everything works as usual.
OK, so for some reason, Cantabile didn’t like that exact Organ Rack. I think something I did in the experimental build made it unstable, probably one of the locked state settings. I have deleted all instances of that organ rack and also deleted the .cantabilerack file.
Back in business. Lesson learned… Don’t mess with important Racks and Songs in experimental builds.
Any Cantabile experts here have any tips if this kind of thing comes up again in the future? Was there a quicker method of diagnosing the problem besides the trial and error I did?
So now I can make my setlist stable as long as VB3 isn’t there in a rack. Sometimes a song with a simple VB3 linked Rack will load. But if I start changing the song midi routings to the VB3 Rack, it causes a crash. Very Strange behavior because it was rock solid up till today when I messed around with the experimental build.
I’ve had crashes in the past with the 64 bit version of VB3, and still haven’t built up enough confidence in it to use it live. So I use the 32 but version and jBridge, and it’s rock solid. That might be worth a go?
Never had any problems with VB3 64. I am still on C3 3232 waiting on a stable version with the new options. I am also still on Win 7. I probably use VB3 on 75% of all my songs and all load perfectly.
Certainly not @brad, but here’s my 2 cents: I was one who, like @Neil_Durant, was experiencing issues with the x64 version of VB3 and had used the 32-bit version. However, several months ago (mainly because of a somewhat irrational obsession to be completely 64-bit), I decided to try the x64 version again, and have not had any issues since.
{quote=“Roland_Robertson, post:10, topic:1359, full:true”]
Certainly not @brad, but here’s my 2 cents: I was one who, like @Neil_Durant, was experiencing issues with the x64 version of VB3 and had used the 32-bit version. However, several months ago (mainly because of a somewhat irrational obsession to be completely 64-bit), I decided to try the x64 version again, and have not had any issues since.
[/quote]
Did you change any windows/cantabile settings since moving to jbridge? Install anything? Uninstall anything?
I know it’s a vague question but this is one of my pet peeves with computer reliability. Sometimes they magically fix themselves! Leaving us scratching our heads forever.
I really don’t know. I have enough plugins and other non-music software on my laptop that the problem could have been almost anything.
And yes, for me, this is one of those “magically fix themselves” situations. Being a software developer in my “real job”, I don’t it like it when (apparently) the same code and the same inputs produce a different outcome.
I’ve contacted VB3’s developer about this (multiple times) and referred him to this topic.
As far as I can tell this is an issue with the plugin itself. In particular I’m suspicious of a pointer truncation issue (the crash reports look like this is the problem) and it partly explains why some users see the issue and some don’t. Basically if Windows gives a particular memory allocation an address >4GB address mark then the pointer gets truncated (bug in the plugin) then the problem occurs. So long as Windows allocates memory below the 4GB mark it’s rock solid. The question is when/why the allocation goes above the 4gb mark - mostly this will be related to the version of the OS, other memory demands, phase of the moon and whether you’re pulling the correct facial expressions.
That’s my best guess anyway… really it’ll need to be resolved in the plugin.
I’d really like to see this issue resolved because many of Cantabile’s users rely on it and it’s a great sounding plugin. I’m willing to provide any and all help to get it resolved but I can’t fix bugs in plugins.
Holy poop… so this could be a potential disaster waiting to happen? I’m pretty much the king of having things be rock stable until an actual gig. Does this bug happen right away on loading? In other words if the plugs for a set load and everything;s ok can one assume it’ll stay that way?
Not sure. Personally I’ve never seen VB3 crash on one of my machines, but I’ve seen enough crash reports to know it’s a problem. I think it usually happens immediately - rather than at some random point in time, but could be wrong.
Apparently wincing eyes and tongue hanging 3/4 of the way out and to the right, as if I was being brilliant, IS the correct facial expression to use when performing with VB3. Problem solved…many thanks Brad ! LOL !!
I can see why those who are experiencing the issue should probably take a leaf out of @Neil_Durant’s book and use jbridge to host VB3. I’m totally guessing at the technical issue here, but I do know that jbridge runs each plugin as if it were a separate app, in its own memory space. Looking at @brad 's post on this issue, perhaps jbridge cocoons the plugin in such a way that the memory issue can’t raise its head?
Ade, I think it’s the fact of running it in 32 bit that prevents the issue, since Brad believes the crash is caused by memory usage outside of the 32 bit memory range, which the 32 bit version could never attempt.
