The Insider News

MS Power User[^]:

LinkedIn Learning combines the content from Lynda.com with LinkedIn’s professional data and network.

Kent Sharkey wrote:

which provides a modern way to access these MIDI interfaces.

• 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.

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);
}

1. Developer has a few silly GitHub projects under his belt and thinks he now knows how to develop an app.
2. Developer wants to feed his ego and prove himself by doing it his way.
3. Developer wants to use the latest newfangled language/framework for no other reason than "it must be better."
4. Developer embraces Agile and starts coding right away with no consideration of the long term issues such as code maintenance, documentation, design, etc.
5. Developer knows tool X and language Y and that's what he'll be using. End of discussion.

article wrote:

nominally