[BUG]: Yamaha MONTAGE M in UMP MIDI2 Mode is detected as "MIDI 1.0 Byte Format"

[JanneRoeper]

Windows Version

10.0.26220 Build 26220 on Arm64

Service Installation Method

In-box In Insider Build

SDK version, if appropriate

1.0.14-rc.1.209 (Arm64X)

Location

Windows MIDI Services Settings App

Type of bug

Cannot receive messages from MIDI 2.0 device

Steps to reproduce

When I first installed the RC1-SDK on my Arm64 Insider-Dev Channel Windows, Yamaha MONTAGE M was recognized (in MIDI Settings App) as UMP MIDI2.0. Using the monitor function I was able to see the UMP MIDI2.0 hi-resolution MIDI messages coming from MONTAGE M. All fine.
Next time I started the system (2 days later), the same MONTAGE M was listed (in Settings App) as MIDI1.0 Byte Format. Using the monitor, I didn't receive anything. I restarted the MIDI Service, did Windows Updates, uninstalled and reinstalled the RC1-SDK and restarted the Computer. Still the MONTAGE M was listed as MIDI1.0 Byte Format. But at least I was able to receive MIDI1.0 in the monitor.
To make sure that MONTAGE M is behaving like it should, I plugged it into my MacBook: UMP MIDI2.0 in Hi-Resolution worked like expected.

Expected behavior

UMP MIDI2.0 should work ;-)

Additional notes

When I open the MONTAGE M in MIDI Settings App (the details page) I get an alert-dialog: "Unhandled Error - Object reference not set to an instance of an object" -> "Ok".
I used a Cubase 15 Windows MIDI2.0 prototype (Arm64EC) to test MIDI2.0 which works and doesn't seem to be related to the described problem which also occurs, if I didn't use Cubase (or any other software besides the MIDI Settings App) after restarting the Computer. Using the Loopback-ports does work in hi-resolution in Cubase.

[Psychlist1972]

This is how the controlled feature rollout works in this insider build, unfortunately.

If you have a system on which Windows MIDI Services has not yet been enabled by the CFR process, this is what happens:

• You plug in the UMP device, which spins up the new driver and the service
• Before Windows has a chance to check CFR and move the device to the MIDI 1 driver, the service starts discovery and protocol negotiation, locking the device. I could have artificially delayed the start of discovery, but that delay has more real impact than this problem during CFR
• Because Windows cannot move the device to the MIDI 1 driver, it does so on the next reboot and so the device is assigned to the MIDI 1 driver, if it supports MIDI 1 fallback.

This happens with UMP devices

On PCs without Windows MIDI Services enabled, the service and the old APIs do not communicate. So any service-specific transports, like UMP, or Loopback, do not have MIDI 1 ports created for WinRT MIDI 1.0 or WinMM MIDI 1.0

The good thing is, as annoying as this can be, it's temporary. The current Insider Dev/Beta releases are a 50/50 test. When we GA in Q1, we will roll out to 100% of devices over a short period.

On Discord in the Dev Updates channel, I posted a preview of a tool which can tell you if Windows MIDI Services is enabled on your PC.

[JanneRoeper]

Ok thanks. I assumed that it may be related to CFR.

[Psychlist1972]

Going to leave this open as I suspect others will run into this over the next couple months.