DirectMusic possible?


#1

Do you think that you could witch the JUCE code for Windows to DirectMusic, i think this could help with the multi-client sharing of MIDI devices, a lot of programs do that and it helps if you want to open the device more then once. I’m getting some bug reports from people trying to open devices that should be multi-client but JUCE crashes when trying to open such devices.
I was wondering have you considered switching to that API ?

There is a nice overview and a demo here http://www.codeproject.com/KB/audio-video/midiports.aspx

and a opensource DirectMIDI implementation (i guess a library over the SDK) that helps with this http://directmidi.sourceforge.net/


#2

Good suggestion, but not something I have time to do in the near future, I’m afraid…


#3

I’d like to bring the topic back since i found this already implemented by someone and was wondering if it would be possible to add a working solution to JUCE, someone already added this and the code is there it just needs to be added, the code is here http://bazaar.launchpad.net/~ace17/acevirus/main/files/head:/lib_rtmidi/, you can find the Kernel Streaming part in RtMidi.cpp (it’s added to the RtMidi library) with a simple Windows interface to IN/OUT (it starts at line 3569), it needs some DDK includes but not a lot, it complained about WINBOOL but adding

#define WINBOOL int

helped and it compiled.

Do you think it would be possible to merge that with JUCE ? Or perhaps make the MIDI devices in JUCE also virtual so we can write our own interfaces like Kernel Streaming and JACK on other platform, in a similar way the AudioFormatManager handles AudioFormats ?


#4

Haven’t got time to think about it at the moment, but if you can suggest changes to the midi classes that’d make it possible without breaking existing code, I’m open to suggestions.


#5

That is some find atom! Thanks for sharing.

Never knew there was a third Midi api on Windows beyond MME and DirectMusic. Even cooler is that from what I see in the code, Sebastien seems to have cracked the only drawback mentioned in this article. That being the other author only got MIDI KS to work with DirectMusic hardware. There was a time when hardware manufactures wrote DirectMusic MIDI drivers but since DM never took off I thought that pretty much stopped. Regardless the code you linked to seems to work with the old MIDI pin meaning any old midi hardware should work.

If you want the lowest possible Midi latency on Windows, Midi KS is probably the way to go.

The author of that Midi KS code (Sebastien) seems to be a fellow Juce dev as well, perhaps he’d be willing to help out?


#6

Hi guys!

Nice to hear you’re interested about my code, it took me quite a lot of time to get it right!
And of course, it works with “normal” MIDI hardware.

sonic59: in fact, KS MIDI is not a real third MIDI API, it’s only the low level layer MME and DirectMusic rely on.

I already submitted my code to the author of RtMidi (as requested by RtMidi’s license), something like 6 months ago ; He asked me for some changes, which I did, but then I got no more e-mails from him. I think he’s very busy, but he told me he was very interested. I did not insist at that time ; however, I’m still very interested getting KS MIDI integrated to RtMidi… or to any MIDI library, JUCE included!

Sebastien


#7

I would certainly be interested in better MIDI support for any platform, especially if it means lower latency or better time-syncing of output messages.


#8

Actually, I think multiple MIDI connections are the main reason why one would use direct kernel streaming instead of MME/DirectMusic.
I may be wrong, but I don’t think the latency/timing improvement will be noticeable.


#9

I tired both and i haven’t seen any timing bumps for better or worse. But get caught in the “only one can open that device” trap and do hate it, though i wish Win8 would solve that having some sort of brand new simple (cause MIDI is simple and should stay that way) MIDI API. But some how MIDI is always left behind, just like me on my prom night, so i know how it feels.


#10

http://8portse.earthvegaconnection.com/DM.htm

http://earthvegaconnection.com/evc/products/miditest/developers.html


#11

LOL, I knew I had forgotten something :slight_smile:
Here it is!
http://bazaar.launchpad.net/~ace17/acevirus/main/revision/355


#12

Since Juce doesn’t really support the selection between multiple different Midi I/O APIs (nor does it really need to), perhaps the best way to implement this would be with ifdefs in juce_win32_Midi.cpp. Developers could then choose between the existing MME (user-mode) code or the new Midi KS (kernel-mode) code at compile time.

Ace17:
Curious if you encountered hard crashses (BSOD) ever during development or usage as this is kernel mode stuff?


#13

Well, technically my code does not run in kernel-mode. Kernel-mode code requires a separate module (.sys file), and uses a totally different API. My code interacts with the kernel in a more direct way (DeviceIoControl) than usual, at the exact same level than MME, and DirectMusic.

You should not be able to cause BSOD from user-mode. However, during development, I crashed my computer (BSOD) a lot of times ; It appears that many MIDI kernel drivers are not very resilient to malformed structures and invalid commands.

In fact, when using a high level API, you have so many layers before reaching the kernel, that most of the time it’s nearly impossible to send invalid data to a device driver. So you don’t see the vulnerabilities of the underlying kernel mode code, until you decide to directly talk to the driver, and then … you better backup your work very often :slight_smile: