[NAME_BUG]: Group names for the Yamaha USB-MIDI Driver not correct

[ReinholdH]

Windows Version

Windows 11 24H2, OS Build 26100.3476 and Windows Canar 27823_prerelease.250321-1420

Service Installation Method

Other (please indicate below)

Location

Windows MIDI Services SDK or tools

Device Make and Model

Yamaha PSR-S910

Name(s) you saw

MIDI

Name(s) you expected

'Digital Keyboard-1' and 'Digital Keyboard-2'

MIDI KS Info Output

MIDI endpoint properties

Additional notes

The group names for the Yamaha USB-MIDI Driver for the 'Yamaha PSR-S910' keyboard are not correctly determined in 1.0.3-preview-12.250322-1519. In the former package 1.0.3-preview-11.250228-237 the names were OK.

To me it looks that 1.0.3-preview-12.250322-1519 does not correctly determine the group names for the Yamaha USB-MIDI Driver. A group name 'MIDI' looks as a kind of default fallback when a name cannot be correctly determined. I conclude that because here the issue #612 with the blank at the end of the group names does not exist.

Interestingly, the Yamaha Steinberg USB Driver V2.1.7 which I use for the 'Yamaha Genos' keyboard is OK as well as the 'USB MIDI cable' (except #612 :-)).

[ReinholdH]

The WinMM ports:

[Psychlist1972]

Thanks for the info. We had an offline discussion, but documenting some things here for anyone following

The generated Group Terminal Blocks will not necessarily have the same name as the WinMM port they are related to.

The reason is because I do not want to bring the older WinMM naming bugs (for example, where all instances of a USB device VID/PID share the same name, even if they actually have different specified names - like with a serial number included) into Windows MIDI Services. They will remain in the WinMM ports for compatibility reasons, but there's a break with Windows MIDI Services UMP endpoints and their related blocks.

I'm interested in understanding any impact here from you and others.

I'm also adding an SDK function to get the WinMM/WinRT MIDI 1.0 ports for a given endpoint so that there can be some association there both in the tools and from apps. I expect to have that in the next public SDK drop. It does break ABI compatibility, but is a necessary change, IMO, after the naming changes.

[ReinholdH]

I'm interested in understanding any impact here from you and others.

So far the default setting for MIDI type in our apps is WinMM. But when UMP is going to become the default, - sometimes hopefully - the impact to the user is the same as described in #522 . Ideally, it would be perfect if for both types the names are the same. But I fully understand the complexity and that now it is the right point in time to provide a clean solution.

My objective is to minimize the effort for the users when UMP will become the default.

From a customers perspective it is not understandable when for a Yamaha PSR-S910 the default names are:

• WinMM 'Digital Keyboard-1'
• UMP MIDI 1.0 'MIDI'

For comparison the Yamaha Genos shows up as:

• WinMM 'Digital Workstation'
• UMP MIDI 1.0 'Digital Workstation'

For comparison the Swissonic MidiConnect 2 cable shows up as:

• WinMM 'USB MIDI Cable'
• UMP MIDI 1.0 'USB MIDI Cable'

For the MIDI devices which I have I investigated the differences of the group name vs. container name.
The result is that for those group names which are shown as 'MIDI' (e.g. Yamaha PSR-S910) the container name ('Digital Keyboard') would be better to use. This is consistent with my other devices.

Looks like that in #611 the Yamaha EAD10 with USBMidi2.sys shows the same outcome.

But there needs to be a clear criterion.

I'm also adding an SDK function to get the WinMM/WinRT MIDI 1.0 ports for a given endpoint so that there can be some association there both in the tools and from apps.

Is this new SDK function the criterion to decide whether to better use the container name than the group name 'MIDI'?
Or, to automatically convert the former WinMM/WinRT MIDI 1.0 port names to the new UMP names in the proprietary .not format for saving music arrangements (see #522) which would be a major relief for our users?

[Psychlist1972]

I'm interested in understanding any impact here from you and others.

So far the default setting for MIDI type in our apps is WinMM. But when UMP is going to become the default, - sometimes hopefully - the impact to the user is the same as described in #522 . Ideally, it would be perfect if for both types the names are the same. But I fully understand the complexity and that now it is the right point in time to provide a clean solution.

My objective is to minimize the effort for the users when UMP will become the default.

I think the port mapping below will address this. Please let me know.

From a customers perspective it is not understandable when for a Yamaha PSR-S910 the default names are:

• WinMM 'Digital Keyboard-1'
• UMP MIDI 1.0 'MIDI'

For comparison the Yamaha Genos shows up as:

• WinMM 'Digital Workstation'
• UMP MIDI 1.0 'Digital Workstation'

For comparison the Swissonic MidiConnect 2 cable shows up as:

• WinMM 'USB MIDI Cable'
• UMP MIDI 1.0 'USB MIDI Cable'

I'm going to look into where "MIDI" is coming from. I assume it's our default when there's no iJack name. But it's not consistent across devices, or even within a single device. Still working on this.

For the MIDI devices which I have I investigated the differences of the group name vs. container name. The result is that for those group names which are shown as 'MIDI' (e.g. Yamaha PSR-S910) the container name ('Digital Keyboard') would be better to use. This is consistent with my other devices.

Looks like that in #611 the Yamaha EAD10 with USBMidi2.sys shows the same outcome.

But there needs to be a clear criterion.

That container name is not 100% WinMM compatible. It's not always the same as the name in the registry, which is what we need to use for the WinMM backwards-compatible naming. Originally I had tried to change that, but for reasons you understand and helped drive, we're going about naming of WinMM using the old algorithms.

Here's a place where it generates the wrong name (in Windows MIDI Services, and also in previous versions of WinMM). Two different devices, but they have the same VID/PID of course:

And for any given VID/PID, there's only one registry entry, and one device "wins". That's the reg key where the WinMM name is pulled from first.

There is no entry for the other ContinuuMini, so both end up with the same WinMM name when using the WinMM-compatible code. It's not 100% the same as the container name because we always have a container name, but don't always have a registry entry, and so WinMM has specific fallback code to generate the name differently, which we need to follow to have compatible naming across all devices.

Mapping Ports

I'm also adding an SDK function to get the WinMM/WinRT MIDI 1.0 ports for a given endpoint so that there can be some association there both in the tools and from apps.

Is this new SDK function the criterion to decide whether to better use the container name than the group name 'MIDI'? Or, to automatically convert the former WinMM/WinRT MIDI 1.0 port names to the new UMP names in the proprietary .not format for saving music arrangements (see #522) which would be a major relief for our users?

For any given parent device, this will be a list of the actual WinMM port names, the group each is associated with, and also the WinRT MIDI 1.0 (the Windows 10 MIDI API) port device id.

For MIDI 1.0 devices, those things will all be 1:1 with the blocks, despite the names.

For MIDI 2.0 devices with function blocks or group terminal blocks spanning groups, it's not 1:1, but you can still use this to map the group to the MIDI 1.0 port.

Call this on the MidiEndpointDeviceInformation object:

And get a vector of this (this is not 100% complete yet):

Each time you call the function it will pull the list fresh, so we don't need to worry about cached values as devices are added/removed.

I think that will meet your requirement of needing to associate those WinMM compatible names in your files when using the new SDK. I'm interested in your thoughts here.

Pete

[Psychlist1972]

@ReinholdH I have this plumbed through to the MIDI console now if you midi endpoint properties. This is easy to call from applications using the SDK. The information provided makes it possible for you to, given a MIDI UMP endpoint, find the associated MIDI 1.0 endpoints.

If you add --verbose, you also get the actual device ids (PortDeviceId in screenshot from previous message)

This is all available from the GetAssociatedMidi1Ports function on the EndpointDeviceInformation object.

Because the WinMM port numbers change when you add / remove devices, each time you call this function it re-queries for the latest device information.

(the ordering when we number the ports is a known issue)

Thoughts?

[Psychlist1972]

Note: there is not currently an efficient way to go the other way around: given a WinMM port index or name, find the associated parent UMP endpoint. I'm looking into this and will put in an inefficient version for now, and change the internal implementation in the future if we're able to add a better cross-reference internally.

Because names are not guaranteed to be unique, that function returns a vector.

[ReinholdH]

@Psychlist1972

Pete, thank you for taking care of such special cases.

Here's a place where it generates the wrong name (in Windows MIDI Services, and also in previous versions of WinMM).

I have another case.

These are the connected MIDI devices

which show up in the registry like this

Interestingly, the Yamaha PRS-S910 does not show up in the registry at all even when it is the only connected device. All VIDs/PIDs of these devices are different. For this Yamaha PRS-S910 the group names 'MIDI' are created. May be because there is no registry entry.

The new mapping functions look very promising to solve the migration WinMM -> UMP scenario. I am looking forward for the new preview update to get my arms around it.

Reinhold

[ReinholdH]

Pete,

Thanks for 1.0.3-preview-12.250406-2129.
I tested GetAssociatedMidi1Ports. This function is very helpful. Thank you very much.

Reinhold

[Psychlist1972]

Pete,

Thanks for 1.0.3-preview-12.250406-2129. I tested GetAssociatedMidi1Ports. This function is very helpful. Thank you very much.

Reinhold

Thanks. I'll continue down the path and implement the other helper functions then. I appreciate your feedback here and pushing in this direction, as it makes for a far more useful SDK for developers moving from winmm to the new SDK.