Incompatible midi driver?

Hi all -

This is my first post here, so first off let me say kudos to Jules and anyone else who has worked on this library. I have seldom found a collection of more intuitive, elegant code libraries.

Second though, I have jumped on here because I have a midi device that causes some issues for me and I was wondering if there is some way to troubleshoot it.

My MAUDIO Keystation 88 pro doesn’t seem to work properly with JUCE. It has no issues starting up, and the callback sees all the messages properly … but everything freezes up on disposal (the program never exits). Is there some explicit method I am missing here?

Code (in class midimanager : midiInputCallback) looks like this:

MidiManager()
{
for (int i = 0; i < devices.size(); i++) {
myMidiDevices[i] = MidiInput::openDevice(i, this);
myMidiDevices[i]->start();
}
}

~MidiManager()
{
for (int i = 0; i < 10; i++) {
if (myMidiDevices[i])
myMidiDevices[i]->stop();
}

}

Works fine for multiple midi devices, as long as the keystation is not one of them.

Yes, sounds like a classic dodgy driver problem… Very hard to guess why it’s freezing, or what you might be able to do alleviate it. If it’s freezing when you call stop(), then you’re pretty much stuffed - might be worth dropping a line to the m-audio guys in that case?

Does it also freeze other non-JUCE programs? If not, how do they manage not to freeze?

I saw lots of stuff like this when I was doing tracktion. (Mostly with m-audio drivers, I have to say…). There’s usually some way that you can do things in a slightly different order that keeps them happy, but there’s no way to find out what it is, except by trial and error.

The first thing to check is your threads - if their code’s not very robust, you might need to make sure you don’t try to close the device while data is arriving, and to make all your driver calls from the same thread…

Yeah I figured something like that. I doesn’t freeze in other applications, though it does have some issues in Reason. It seems to work with RTMidi based programs (I’ve written a few that use it) … though I should test more thoroughly on that.

I also tried initializing the midi on the audiodevicecallback thread instead of on it’s own (with the audio device and audio device callback instead of in a separate class). Same result though. I’m curious if that is the preferred method?

Also - Can JUCE share the audio driver with other apps? is there a setting for that? I want to let a few different programs access an ASIO based driver at once … but JUCE seems to lock it.

ok … cool. I’ve got more trial and error to do with this MAUDIO guy, and will be sure to post if I figure out a workaround. Thanks for the quick reply … I really have been impressed with JUCE so far … it’s let me rewrite some applications in record time, with new features and half the code length … so woohoo! I particularly like how easy it is to construct a “visualizer” for the audio waveform. I can’t wait to really start applying effects/transforms/etc. and see if the performance holds up.

Thanks,
Aaron