Specifications can be funny. As much as the MIDI Association, and all of us in it, try to be very specific and crisp on wording, there’s often room for interpretation. Most of these we work out among the various OS companies under the umbrella of the MIDI Association. But there are others were an approach may just not make sense on one OS or the other. Here are the ones that are Windows-specific, that you should be aware of as a developer.
Of course, the full source code for Windows MIDI Services, including the USB MIDI 2.0 driver, is available in our GitHub repo, linked at the bottom of every page, so you can review it at any time to better understand how a feature or function works.
Windows MIDI Services supports only the UMP-based Endpoint Discovery and Protocol Negotiation. We do not implement the deprecated MIDI-CI equivalents. We also do not wrap or automatically perform MIDI 1.0 SysEx-based discovery.
The hardware manufacturers, AMEI, and the MIDI Association agreed that JR Timestamp handling in the operating systems is not needed at this time (and may not be needed for many years). As a result, we do not have JR Timestamp handling built in. Please do not request or supply JR Timestamps.
When (if) it is needed, we will implement JR clock generation, incoming JR timestamp generation, and outgoing JR timestamp/clock message creation in the service itself. Client applications should not send JR timestamps now or in the future.
Internally in Windows MIDI Services, all messages are UMP messages, whether they come from a MIDI 1.0 byte data format device, a UMP-native device or API, or a MIDI 1.0 classic API. This requires Windows to perform message data format translation in some cases.
Translation happens as described in the translation page
Although we make all the names available through the Enumeration API, we have an order of precedence we use when providing the recommended Name property value. In order from most preferred to least, we have:
When we create MIDI 1.0-compatible ports for MIDI 2.0 endpoints, we use the group numbers and the endpoint name. However, we also have built-in naming algorithms that are different for native MIDI 1.0 devices, including both WinMM-compatible naming, and more modern naming which also uses the iJack/Pin values. We are limited to 32 characters for WinMM ports.
The service also creates UMP endpoints for MIDI 1.0 devices. This happens two ways:
iJack names, if provided, to name the Group Terminal Blocks. This is the best way to ensure your endpoint and Group Terminal Block names are correct.The precedence for naming is the same as with MIDI 2.0 devices, with the exception of the Endpoint Name Notification, which doesn’t exist in MIDI 1.0.
How MIDI 1.0 names are picked is set, by endpoint and globally, using the MIDI Settings app. In that, you can override naming algorithms or even provide custom names.
If your device exposes a unique iSerialNumber, that will really help with retaining name and other information across physical USB connects and disconnects. We do our best to retain the correct information if you plug into the same physical port, but when you change ports, a device without an iSerialNumber essentially becomes a new device. This is not unique to Windows, but it’s important enough to mention here. More info and guidance in this blog post.
Windows MIDI Services is an open source project with all source available on GitHub. We have a great community on Discord as well. Between GitHub and Discord, you should find the information you are looking for.
