didn't check the code, but maybe it would make sense to provide a deinitMIDI function, which will be called at the time of the library shutdown ... i had been doing this for the new HID primitives and it should probably be done for every primitive which allocates resources/threads.

There's already a de-initialization function, but that's precisely the problem. After initializing the midi client, then de-initializing, future attempts to initialize will fail -- causing bad bugs. We're barely using the MIDI client - it's only required as an argument to a few other calls - so there's not much massaging of code on the SC side to be done. I suspect it's either not intended to be repeatedly created and destroyed as we're doing, or if it is, nobody is doing it except for us and there are lurking bugs. Regardless, I don't see any reason why we can't just carry it over between Library rebuilds. Note that we still init and de-init midi connections we make between library recompiles - this seems to work just fine.

What's the best way to test this ? create a midi responder and recompile the library, repeat vigorously ?

arg. this is so old that it won't build with my current up to date qt5 sc set up.

Regardless, I don't see any reason why we can't just carry it over between Library rebuilds.

A library rebuild is supposed to behave exactly like a restart of sclang, so maybe better not.

@telephon - You're right - but, this is seemingly a problem with the CoreMIDI API's, so there's no other option to avoid the crash. AFAICT once we've called MIDIClientDispose, we can't call MIDIClientCreate again. In lieu of a specific problem happening because of the client re-use, it seems better to opt for avoiding the crash....

@crucialfelix - I saw this all the time in a workflow that looked like: (a) compile lang (b) create and init client (c) use midi, (d) recompile (e) repeat..... In an afternoon of working, I would see this crash ten or twelve times - not on every recompile, but it was not uncommon either.

@crucialfelix - I just updated this branch but didn't see any merge conflicts or anything - what's the build problem you're seeing?

I've experienced the bug myself in the past. Very happy to see a potential
fix.

If I check out the branch I couldn't just build it because I have to switch
my qt, clean build, set cmake the same way we used to do it. The new build
system is much nicer

Or we just merge it and test in master.
On Sat, May 23, 2015 at 8:38 PM scztt notifications@github.com wrote:

@crucialfelix https://github.com/crucialfelix - I just updated this
branch but didn't see any merge conflicts or anything - what's the build
problem you're seeing?

—
Reply to this email directly or view it on GitHub
#1147 (comment)
.

I'm okay with merging and testing in master - I would consider this a safe fix. @telephon - can you merge if you're okay, or else let us know if there are any problems related to reusing the MIDI client?

I don't use MIDI, so I can't test. But I think this fix for now is better than nothing.

@scztt many thanks for fixing this longstanding issue.

i can confirm that it is now fixed. in my previous build (21c661b) and earlier it was easy to crash sc with...

MIDIClient.init
//recompile
MIDIClient.init
//crash -> 'Interpreter has crashed or stopped forcefully. [Exit code: 0]'

and you'd get this even without any midi gear connected.
with latest build it doesn't crash. thanks again.

All Hail @scztt Exterminator of The Bug !