critical issue with Isadora continuously crashing on launch
It appears to be my turn to have a critical issue with Isadora continuously crashing on launch on the eve of a major production (opening night is Tomorrow) EEEK!
Running IsadoraUSB 2.5.2 on MacBookPro 2011 Mac OS Sierra. Isadora application quits unexpectedly on every launch. Can't think what has changed - have not edited the patch significantly and has worked for days. The only other use for the machine has been to open a .wav file and convert to .mov using Quicktime 7.
I have done a fresh install but still crashing on launch!!!
[Edit] Have deleted Isadora Preferences and opened a prior iteration of the patch and Isadora has launched successfully. I then remembered what had happened earlier in the day when a journalist came into the venue to conduct an interview with the artist and asked to hear the prerecorded sound track which I dropped into Isadora as a .wav and .mov, the files are about 1.8gb each and have the same file name. Even so Isadora was crashing on launch without attempting to open a patch - deleting the preferences took care of that but the patch file continues to crash.
[Edit II] Have managed to restore the file by moving the offending audio file out of the project folder - to break the file reference link in the patch file - I could then open the patch file in Isadora and delete the audio file reference from the Media Bin.
So onwards to the next trouble shooting spot in the production!
Crash report attached
Glad you worked it out. It's usually an illegal video / stage setup or media related. So you handled it perfectly.
Does this only happen when you import both files?
mark last edited by mark
The crash report shows that Isadora was crashing when it attempting to import the sound file. The thing about the Sound Files (.aiff and .wav) is that Isadora imports sound files into RAM. It does this because the original purpose of the sound file feature was to be able to trigger sound playback with nearly zero latency, just as you would with a sampler. (This approach dates back to day 1 of Isadora, when I was only using it for my own pieces and I needed to trigger samples interactively. I wanted to be able to do that inside Isadora; if the files were on disk, the delay between trigger and playback was simply too long.)
In any case, the whole audio part of Isadora needs attention. I've filed a bug report on this so we won't lose track of it. We'll at least come up with an immediate solution in the form of a warning. That said, we've many audio improvements on our "to do" list for Isadora 3.
Sorry for the inconvenience of the crash.
Hi Michel, to answer your question only the .wav file made it into the media bin. So there was only the one fugitive audio file to deal with in the end.
On reflection, it feels like this is the first time I have had to find and delete Isadora Preferences in over a decade. And on that older machine (running Isadora since 2011) there were quite a few versions of Isadora preference files (all now deleted) going back to pre Isadora 1.3 - I think. Anyway it is a testimony to how stable Isadora is as a program considering the amount of I/O and file passing work it does. Unfortunately, I have to reset my (hypothetical) crash counter between terminal crash incidents.
Isadora imports sound files into RAM.
That is very good to know, I assume that fact is outlined in the Isadora manual, but I suspect like most, I don’t always get to the manual before making moves when patching. Anyway experimentation is an effective way of learning - finding out the hard way what does not work, to really know what does.
Are you suggesting an implementation where the size of the audio file is detected by Isadora and its potential impact in the system is reported in a warning before it is allowed to be added to the media bin?