The Insider News

Jeremy Falcon wrote:

It would be a fun idea to make a console-based Tetris game, methinks, showing it off.

Kent Sharkey wrote:

I'm so glad that the feedback they listen to is, "we want more colours in the command shell"

BillWoodruff wrote:

Note: I mis-read the article as saying 500k accounts were hacked, perhaps because I couldn't imagine Yahoo having 500 million users. I still have trouble believing that.

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