It looks like this has been on the to-do list for a while.
I read about the workaround: set up a basic poller checking for MidiOutput::getDevices(). But, my list of devices never changes…
Since I’m on OSX, do I have to hack on the CoreMIDI NotifyProc if I want to get this going?
Yeah, it’s a to-do-list item, sorry.
I’ve been told by several others that repeatedly polling GetDevices() has worked previously, but for me it does not reflect added or removed MIDI devices.
I’m not interested in proper add/remove callbacks which, although much more convenient, aren’t high priority.
This post also describes the same problem: http://www.rawmaterialsoftware.com/viewtopic.php?f=2&t=8322&hilit=midi+10.5.8
I was beginning to think this was a CoreMIDI bug, but considering how Ableton Live or GarageBand updates their lists on the same platform, I fail to see why GetDevices() isn’t able to achieve the same functionality other than a missing call to something, somewhere. Thoughts?
We saw this once, because of a threading issue.
Mac OS uses a messaging system for updating this list, and so for this to happen someone has to read the messages.
When coding a single threaded utility command line utility where we never called the message pump, we noticed this behavior. If I recalled well, we solved this issue by calling MessageManager::runDispatchLoopUntil() or similar
Interesting. Indeed that works…
I was using a TimeSliceThread to monitor for the changes. It looked like the MessageManager was running, but it seems like that thread was being blocked by the TimeSliceThread?
The solution is easy (user a timer), but even with MessageManagerLocks I couldn’t get it to go.
It’d be great if MidiInput had a Listener with insert / remove notifications and all this background thread business was neatly tucked away in a JUCE implementation (that works on all platforms).
Upvote on TheVinn’s suggestion.
Actually I am going to go ahead and put together an implementation in VFLib. I need this feature, and I know that Jules has a bunch of stuff to do. I should have something in relatively short order.
I see a problem. What happens if the device gets disconnected and reconnected before the periodic re-scan of the device list occurs? The MidiInput and MidiOutput objects have to expose some functionality that shows when the operating-system specific connection has been broken (perhaps by detecting an error code).
Wouldn’t that depend as to how often you re-scan, or can re-scan?
Perhaps, but to have a robust implementation it is necessary to know at the system level if the existing connection has been broken.
On Mac OS X, there is the MIDINotifyProc. It tells you that the MIDI setup has changed.
Unfortunately, I don’t think there is a Windows equivalent. Maybe something at the USB level.
[quote=“ke20”]On Mac OS X, there is the MIDINotifyProc. It tells you that the MIDI setup has changed.
Unfortunately, I don’t think there is a Windows equivalent. Maybe something at the USB level.[/quote]
I spent all day trying to figure out a way to do something on Windows but there is nothing. The Windows MIDI API truly sucks. The USB API would probably be the way to go.
MME was written back in 1991 for Windows 3.0.
Did you look into KS Midi?
Maybe if we are lucky the hardware is given a unique GUID each time it is connected? Or maybe that’s just wishful thinking. Ace17 will probably know the answer to that.
Well I just looked over the code in that repository and it uses RtMidi, which calls midiGetNumDevs() and midiInOpen() both of which refer to devices by index and not a unique ID.
It’s not looking good for Windows…
I think you are referring to the MME code in RtMidi.cpp at line 2528.
I was talking about the KS Midi code in RtMidi.cpp at line 3569 which uses the KS Midi code which Ace17 wrote.
And if we are really lucky, this may solve the issue you mentioned in your Behavior of MidiInput::getDevices() has changed? post about unique device names for multiple identical hardware.
[quote=“sonic59”]I think you are referring to the MME code in RtMidi.cpp at line 2528.
I was talking about the KS Midi code in RtMidi.cpp at line 3569 which uses the KS Midi code which Ace17 wrote.[/quote]
All true. Okay, so KS uses the “Direct Kernel Streaming” API. This could be an interesting alternative but it is listed under “legacy interfaces.”
Well one could argue that MME and DirectMusic are legacy interfaces as well.
As I understand it, MME and DirectMusic are user-mode MIDI API’s built on top of the kernel-mode KS API.
