MIDI Enhancements in Windows 10
-
In Windows 10 RTM last year we introduced a new MIDI API, accessible to UWP Apps on virtually all Windows 10 devices, which provides a modern way to access these MIDI interfaces.
"By pressing down a special key, it plays a little melody"
-
In Windows 10 RTM last year we introduced a new MIDI API, accessible to UWP Apps on virtually all Windows 10 devices, which provides a modern way to access these MIDI interfaces.
"By pressing down a special key, it plays a little melody"
Kent Sharkey wrote:
which provides a modern way to access these MIDI interfaces.
And, note how mums-the-word on what, exactly, Windows 7 & 8 "provide[d as it pertains to] a way to access MIDI devices".
-
In Windows 10 RTM last year we introduced a new MIDI API, accessible to UWP Apps on virtually all Windows 10 devices, which provides a modern way to access these MIDI interfaces.
"By pressing down a special key, it plays a little melody"
They could make it tighter timing wise. But no. now the ill fated uw get midi - yawn, and the rest of us get a wrapper and it's overhead.
-
In Windows 10 RTM last year we introduced a new MIDI API, accessible to UWP Apps on virtually all Windows 10 devices, which provides a modern way to access these MIDI interfaces.
"By pressing down a special key, it plays a little melody"
Hi All I'm the author of the blog post here. Through the wonders of the web, I've found you all referencing it. :) Some clarification for you: - We've had (and still have) two previous MIDI APIs: DirectMusic and MME. Both of those are still available, but only work on desktop PCs. They're also not flexible enough to easily handle new transports like Bluetooth in a way we were happy with. - We did fix some minor MIDI Jitter and timing in Windows 10 RTM when we created this API. In the end, however, you're at the mercy of USB which, given how it routes, is going to add a very small amount of jitter and latency. Those amounts are still less than the DIN MIDI wire speed, though. Of course, Bluetooth has higher latency and jitter and depends on quality of space in the room. We're competitive with what Apple does there (and compatible with them), but it's not as tight as USB. For that reason, many people tend to use Bluetooth MIDI for secondary controls, not for banging our riffs on a keyboard. You can, but IMO, it's not the best experience. - The way DAWs typically deal with latency and jitter is to schedule MIDI messages. We don't have that yet, but it's on the backlog for consideration. - In our own testing, the wrapper doesn't add any meaningful latency; it's working at function call speeds. The UWP MIDI APIs were always accessible to desktop applications (not true of all UWP APIs) but some companies felt the ceremony required to call from a Win32 app was a bit ... opaque. I agree, so had this work done by a colleague on the team. Feel free to take a look at the code on GitHub and try it out. We're happy to consider pull requests if you have suggestions. ```c++ void winrt_midi_out_port_send(WinRTMidiOutPortPtr port, const unsigned char* message, unsigned int nBytes) { MidiOutPortWrapper* wrapper = (MidiOutPortWrapper*)port; wrapper->getPort()->Send(message, nBytes); } ... void WinRTMidiOutPort::Send(const unsigned char* message, unsigned int nBytes) { // check if preallocated IBuffer is big enough and reallocate if needed if (nBytes > mBuffer->Capacity) { mBuffer = ref new Buffer(nBytes); mBufferData = getIBufferDataPtr(mBuffer); } memcpy_s(mBufferData, nBytes, message, nBytes); mBuffer->Length = nBytes; mMidiOutPort->SendBuffer(mBuffer); } ``` Beyond that, it's worth pointing out that many have been using MIDI wrapper libraries since the dawn of time. It's never really been a problem. The C# helper library I wro
-
Hi All I'm the author of the blog post here. Through the wonders of the web, I've found you all referencing it. :) Some clarification for you: - We've had (and still have) two previous MIDI APIs: DirectMusic and MME. Both of those are still available, but only work on desktop PCs. They're also not flexible enough to easily handle new transports like Bluetooth in a way we were happy with. - We did fix some minor MIDI Jitter and timing in Windows 10 RTM when we created this API. In the end, however, you're at the mercy of USB which, given how it routes, is going to add a very small amount of jitter and latency. Those amounts are still less than the DIN MIDI wire speed, though. Of course, Bluetooth has higher latency and jitter and depends on quality of space in the room. We're competitive with what Apple does there (and compatible with them), but it's not as tight as USB. For that reason, many people tend to use Bluetooth MIDI for secondary controls, not for banging our riffs on a keyboard. You can, but IMO, it's not the best experience. - The way DAWs typically deal with latency and jitter is to schedule MIDI messages. We don't have that yet, but it's on the backlog for consideration. - In our own testing, the wrapper doesn't add any meaningful latency; it's working at function call speeds. The UWP MIDI APIs were always accessible to desktop applications (not true of all UWP APIs) but some companies felt the ceremony required to call from a Win32 app was a bit ... opaque. I agree, so had this work done by a colleague on the team. Feel free to take a look at the code on GitHub and try it out. We're happy to consider pull requests if you have suggestions. ```c++ void winrt_midi_out_port_send(WinRTMidiOutPortPtr port, const unsigned char* message, unsigned int nBytes) { MidiOutPortWrapper* wrapper = (MidiOutPortWrapper*)port; wrapper->getPort()->Send(message, nBytes); } ... void WinRTMidiOutPort::Send(const unsigned char* message, unsigned int nBytes) { // check if preallocated IBuffer is big enough and reallocate if needed if (nBytes > mBuffer->Capacity) { mBuffer = ref new Buffer(nBytes); mBufferData = getIBufferDataPtr(mBuffer); } memcpy_s(mBufferData, nBytes, message, nBytes); mBuffer->Length = nBytes; mMidiOutPort->SendBuffer(mBuffer); } ``` Beyond that, it's worth pointing out that many have been using MIDI wrapper libraries since the dawn of time. It's never really been a problem. The C# helper library I wro
You've only waited 11 years to come back to Code Project :) Welcome back Pete.
This space for rent
-
You've only waited 11 years to come back to Code Project :) Welcome back Pete.
This space for rent
Heh, thanks Pete. Yes, it has been quit a while. CodeProject thinks it was 1999 when I was last on, but my message history says it hasn't been quite that long. :) Pete
-
Heh, thanks Pete. Yes, it has been quit a while. CodeProject thinks it was 1999 when I was last on, but my message history says it hasn't been quite that long. :) Pete
-
Pass the word around the office, Pete - a bigger Microsoft dev (or even evangelist) presence on CodeProject would, I think, not be unwelcome.
Thanks Mick I'm in Windows now, no longer in evangelism. In DX/DPE, most of the evangelists are doing Azure these days. I would need to look back around here to see if that's a fit. I feel like there used to be many communities we were all involved with but have since lost touch with. I'm active in some music communities, but not so much in places like Code Project these days. Pete