[BUG] Single MIDI streaming interface shows up as multiple UMP endpoints.

[m-komo]

Describe the bug
Roland OCTA-CAPTURE is a vendor specific USB MIDI 1.0 device, and it has two MIDI ports named "MIDI" and "CTRL".
The device consists of two MIDI port objects as below:

If I enumerate UMP endpoints, two "OCTA-CAPTURE" endpoints show up.

However, since the device only has a single USB MIDI stream, it should be configured as a single UMP endpoint.

And also, if I run the "send-message" command on both UMP endpoints, no message was sent out to the USB stream.

This issue may occur not only on the OCTA-CAPTURE but also other devices which have similar topology.

To Reproduce

1. Attach the Roland OCTA-CAPTURE to the PC and wait for a while for the driver to be installed automatically.
2. With any MIDI 1.0 app, make sure that two MIDI ports named "MIDI" and "CTRL" exist.
3. Run 'midi enum ump' to enumerate UMP endpoints for the OCTA-CAPTURE.
4. Run 'midi endpoint send-message' on any of OCTA-CAPTURE's UMP endpoint.

Expected behavior
Only a single UMP endpoint shows up for OCTA-CAPTURE.
Sent messages are sent out to the USB stream.

Screenshots
Device Properties.zip
Attached file contains two files:

• Devices on MIDI settings.png: Screenshot of the MIDI settings app.
• Endpoint Properties.txt: Output of 'midi endpoint properties' command.

Installer Name or Version

• Service: Windows.MIDI.Services.Developer.Preview.5.x64.1.0.24066.2126.exe
• Driver: Updated_USBMIDI2_10.0.1.4.zip

Desktop (please complete the following information):

• OS: Windows 11
• OS Build: 26090.1

Device information, if this is with an external MIDI device:

• Device: Roland OCTA-CAPTURE
• Driver: OCTA-CAPTURE driver ver.1.5.3 for Windows 10/11

[m-komo]

And also, if I run the "send-message" command on both UMP endpoints, no message was sent out to the USB stream.

This was my misunderstanding.
Messages were sent out to the USB stream correctly.

So now, the question is why two UMP endpoints show up? Is this related to the Issue#184?

[Psychlist1972]

@m-komo I assume this shows up as two separate devices under "Sound, video and game controllers" in Device Manager? If so, then it has two separate MIDI streaming interfaces, and we'll see it as two distinct MIDI devices. (Our naming for those devices is not currently correct. I'll need to see the descriptors for this device to see where the names are set).

What I believe is happening here is the device exposes two separate MIDI interfaces, and each has separate pins (pin 0 and 1 from each). It really depends on what the driver is surfacing to us, though.

I don't have one of these devices. Do you have any info on the descriptors it exposes?

[m-komo]

@Psychlist1972

The device has a single MIDI interface with two endpoints for input and output and it shows up as a single device under "Sound, video and game controllers" in Device Manager.
As you can see in the screenshot of KSStudio, our driver instantiates two port objects to name each port.

I noticed we can reproduce this with the A-88mkII running in the vendor specific mode.

Could you try with it?

You can download A-88 mkII driver for Windows from below:
https://www.roland.com/global/support/by_product/a-88mk2/updates_drivers/0de54026-b31b-45ae-9d2c-975247eb01e4/

Please see Owners Manuals to switch the A-88 mkII to the vendor specific mode.
https://www.roland.com/global/products/a-88mk2/support/

[Psychlist1972]

I'll try this with the A-88mk2. However, Gary explained the logic here. If there are multiple filters, it will show up as multiple endpoints. That's how it works with MIDI 1.0 and the classic APIs.

We can consider different logic here, but it wasn't in our plans to date.

Going to leave this one open not because it's actually a bug (it works today like it did in the past), but it's a behavioral change we can consider implementing.

[m-komo]

Implementing multiple filters is common way to name each MIDI port.
In fact, there are same cases with several third-party vendor products.

As you pointed, it should work fine with applications which use the classic APIs (MIDI 1.0 APIs).
However, there are some concerns when using the MIDI 2.0 APIs.

• Since all filters are configured as UMP endpoints with the same name, it is impossible to distinguish which MIDI port each UMP endpoint connects to.

• It is not possible to sort-out and manage messages by group number when playing and recording UMP messages to/from multiple UMP endpoints.

Followings are possible examples of what happens if a single MIDI 1.0 streaming interface is divided to multiple UMP endpoints:

• It is not possible to play back a data which contains UMP messages with multiple group numbers, such as a MIDI Clip file, on a single UMP endpoint.

• When recording UMP messages from multiple UMP endpoints, all UMP messages are received with a same group number (group index 0). Recorded UMP messages cannot be merged and saved without re-setting group number.

These will be an obstacle and a limitation to using existing MIDI 1.0 devices from applications that use MIDI 2.0 APIs.
I don't know how to do it, but we need to find some kind of solution.

[dmiura]

Yamaha also check it with our product Montage(not Montage M) which use vendor USB MIDI 1.0 driver.
Montage has 3 ports.
Vendor Driver: https://usa.yamaha.com/support/updates/yamaha_steinberg_usb_driver_for_win.html

Result: midi.exe shows 3 UMP Endpoint with same name.

Also we checked using ksstudio, it shows three separated name, like MONTAGE-1, MONTAGE-2 and MONTAGE-3.

[Psychlist1972]

Naming is not yet finalized because Gary and Julia are re-doing the MIDI 1.0 enumeration code (main issue right now is devices only show up if they have a single in and a single out). But it's good to know that you use the filters for naming, instead of iJack. So many ways to provide names for devices, unfortunately.

[Psychlist1972]

I'm bringing the filter thing back to Gary and Julia for consideration. I don't know if this can work within the Windows USB structure, and what will happen if other devices use filters in other ways, but they will know.

[MusicMaker]

@m-komo do you have a USB device & config descriptor(s) descriptor dump ? Would like to experiment with that.

[m-komo]

Hi @MusicMaker,
I have attached the descriptor dump file.
Since it is the vendor specific class, it may not be helpful for you.
A-88MK2.txt

[Psychlist1972]

This has been implemented in DP8. See details in #456

[MusicMaker]

Question, Shouldn't vendor specific devices still use their legacy driver and then be handled by the service instead of the class compliant MIDI 2.0 driver ?

[Psychlist1972]

Question, Shouldn't vendor specific devices still use their legacy driver and then be handled by the service instead of the class compliant MIDI 2.0 driver ?

A vendor-specific device that is not class-compliant cannot use the UMP USB MIDI 2.0 class driver

The KS (Kernel Streaming) transport handles anything which is attached to the new UMP driver, both MIDI 1.0 Class-compliant and MIDI 2.0 Class-compliant devices.

The KSA (Kernel Streaming Aggregate) transport handles anything which is a kernel streaming driver that exposes one or more MIDI 1.0 byte format pins. That includes vendor-specific MIDI 1.0 devices as well as the older MIDI 1.0 class driver.

We don't automatically repoint, at least for now, MIDI 1.0 class-compliant devices to the new UMP class driver, even though the new driver is faster and can support them. We may do that in a future release once we're sure about compatibility, but there can be cases with older MIDI devices where they make assumptions about being part of the USB Audio Class 1 driver, which would break some or all functionality if they are assigned to the new separated UMP driver. Technical users are able to repoint their class-compliant MIDI 1.0 devices to the new driver manually if they want to.

[garydan42]

Pnp will always pick the most specific driver available, most specific meaning an inf that specifies the most complete matching hardware id. The class driver doesn’t specify a hardware id, just a class. This means that a vendor provided driver will always be chosen over the class driver. Overriding this behavior is impractical. The pnp stack will always revert to the vendor driver after an OS update or whenever there’s an updated vendor driver published, so any modifications done by the user or service to change the pnp behavior will not reliably persist. Adding the hardware ids to the class driver will also not work because the creation date for inbox drivers, including class drivers, is set to the 1980’s, intentionally, so that all vendor drivers will look newer. This way vendor drivers are favored in the event an inbox driver specifies a hardware id. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Pete Brown ***@***.***> Sent: Friday, December 6, 2024 10:46 PM To: microsoft/MIDI ***@***.***> Cc: Assign ***@***.***> Subject: Re: [microsoft/MIDI] [BUG] Single MIDI streaming interface shows up as multiple UMP endpoints. (Issue #305) Question, Shouldn't vendor specific devices still use their legacy driver and then be handled by the service instead of the class compliant MIDI 2.0 driver ? A vendor-specific device that is not class-compliant cannot use the UMP USB MIDI 2.0 class driver The KS (Kernel Streaming) transport handles anything which is attached to the new UMP driver, both MIDI 1.0 Class-compliant and MIDI 2.0 Class-compliant devices. The KSA (Kernel Streaming Aggregate) transport handles anything which is a kernel streaming driver that exposes one or more MIDI 1.0 byte format pins. That includes vendor-specific MIDI 1.0 devices as well as the older MIDI 1.0 class driver. We don't automatically repoint, at least for now, MIDI 1.0 class-compliant devices to the new UMP class driver, even though the new driver is faster and can support them. We may do that in a future release once we're sure about compatibility, but there can be cases with older MIDI devices where they make assumptions about being part of the USB Audio Class 1 driver, which would break some or all functionality if they are assigned to the new separated UMP driver. Technical users are able to repoint their class-compliant MIDI 1.0 devices to the new driver manually if they want to. — Reply to this email directly, view it on GitHub<#305 (comment)> or unsubscribe<https://github.com/notifications/unsubscribe-auth/AOXSFVENM7ZFBHSX63DLOD32EJVPPBFKMF2HI4TJMJ2XIZLTTCBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVI2DCNRUGYZDIMBWG6SG4YLNMWUWQYLTL5WGCYTFNSBKK5TBNR2WLKRVGYZTKNBTGUYTANVENZQW2ZNJNBQXGX3MMFRGK3ECUV3GC3DVMWVDKNRTGYYDGNRRGY22I3TBNVS2S2DBONPWYYLCMVWIFJLWMFWHKZNKGU3DIOJSGYYTMMBYURXGC3LFVFUGC427NRQWEZLMQKSXMYLMOVS2UNZYGM3DANZTGQYTTJDOMFWWLKLIMFZV63DBMJSWZLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOLYFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVE2DSNJZGU4TINZRQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRSGIYTSNZUGYZDEOECUR2HS4DFUVWGCYTFNSSXMYLMOVS2UNBRGY2DMMRUGA3DPAVEOR4XAZNFNRQWEZLMUV3GC3DVMWVDKNRTGU2DGNJRGA3IFJDUPFYGLJLMMFRGK3FFOZQWY5LFVI2TMMZWGAZTMMJWGWBKI5DZOBS2K3DBMJSWZJLWMFWHKZNKGU3DIOJSGYYTMMBYQKSHI6LQMWSWYYLCMVWKK5TBNR2WLKRXHAZTMMBXGM2DCONHORZGSZ3HMVZKMY3SMVQXIZI>. You are receiving this email because you were assigned. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Psychlist1972]

DP8 now shows a single physical device with multiple KS filters/endpoints as a single device when using vendor or class MIDI 1.0 drivers.