[NAME_BUG]: GTB and MIDI 1 Port Names of 'DTX-MULTI 12' not correctly set when using KS, but are fine with KSA

[sat-okada]

Windows Version

27823.rs_prerelease.250321-1420

Service Installation Method

Other (please indicate below)

Location

App using Windows MIDI Services SDK (MIDI 2.0)

Device Make and Model

YAMAHA DTX-MULTI 12

Name(s) you saw

YAMAHA DTX-MULTI 12/YAMAHA DTX-MULTI 12/YAMAHA DTX-MULTI 12

Name(s) you expected

YAMAHA DTX-MULTI 12/MIDIIN2/MIDIIN3

MIDI KS Info Output

MIDI endpoint properties

Additional notes

SDK Version : 1.0.3-preview-12.250406-2129 (from Discord)

The output results from USBAUDIO.sys is here.

[Psychlist1972]

Thanks. I'll take a look at this. MIDIIN2 (YAMAHA DTX-MULTI 12) is 29 characters. We're allowed 32 total in WinMM including terminating null, so I may be reserving too many at some point in the code.

[m-komo]

This seems to occurs not only on specific product (YAMAHA DTX), but also on MIDI 1.0 products which have multiple MIDI ports.

The attached firmware (UUT_ZOA_104(no String).uf2) can be used to reproduce this on the ProtoZOA.
If the device is running with the USB MIDI 2.0 driver, all WinMM ports have same name and all GTB names are empty.

Followings are output of 'midiksinfo', 'midi1enum' and 'midi ep properties':

• ZOA-104_properties_KS.txt
  This is the case of using KS (USBMidi2.sys). All WinMM ports have same name "ZOA-104" and all GTB names are empty.

• ZOA-104_properties_KSA.txt
  This is the case of using KSA (USBAUDIO.sys). No probrem.

I'm not sure, but it seems to be related to #611.

[sat-okada]

I found a problem regarding this issue, so add comment.

The following steps cause a problem:

1. Load the attached ZoB.uf2.zip firmware to the ProtoZOA.
   Followings are output of 'midiksinfo', 'midi1enum' and 'midi ep properties':
   ZOB_KS.txt

2. Attach the ProtoZOA to the PC and make sure that USB MIDI 2.0 driver (UsbMidi2.sys) is loaded.

3. Launch Pocket MIDI and select Input.

All ports of ZoB are displayed as ZoB GTB1.

4. Select the second ZoB GTB1 from the top.

5. When see Input again, the first ZoB GTB1 is selected.

6. Select Output in the same way.

7. Pressing a key in the Keyboard window sends a message on the selected port number.

expected behavior:
When see Input again, the port at the selected position appears to be selected.

This behavior may be a problem in Pocket MIDI, but it could also be caused by the fact that all the port names are the same.

[Psychlist1972]

I found a problem regarding this issue, so add comment.

The following steps cause a problem:

1. Load the attached ZoB.uf2.zip firmware to the ProtoZOA.
   Followings are output of 'midiksinfo', 'midi1enum' and 'midi ep properties':
   ZOB_KS.txt
2. Attach the ProtoZOA to the PC and make sure that USB MIDI 2.0 driver (UsbMidi2.sys) is loaded.
3. Launch Pocket MIDI and select Input.

All ports of ZoB are displayed as ZoB GTB1.

4. Select the second ZoB GTB1 from the top.
5. When see Input again, the first ZoB GTB1 is selected.
6. Select Output in the same way.
7. Pressing a key in the Keyboard window sends a message on the selected port number.

expected behavior: When see Input again, the port at the selected position appears to be selected.

This behavior may be a problem in Pocket MIDI, but it could also be caused by the fact that all the port names are the same.

What are the GTB names in the ProtoZOA Firmware itself? Are they empty? Something else? For UMP native devices, we assume the group terminal blocks are correctly named and we try to use them as-is when creating MIDI 1 ports. But I may have a bug there if the names in the device are not what you are seeing.

This is another one of those instances where being able to look at the ProtoZOA firmware source code could really save some time vs debugging a kernel driver.

Looking through the binary uf2 and searching for strings, it appears the Group Terminal Block names are GTB1-GTB16. Is that correct? If so, there's a bug in my logic in the service.

[sat-okada]

ZoB has one Group Terminal Block with 16 Group Terminals.
GTB name is "GTB1".
The Function Block has 4 names.
See the following image.

Refer to the following statements.
Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol Document Version 1.1.1
Appendix I: Using USB MIDI Group Terminal Blocks and Function Blocks

One strategy to avoid this conflict is to declare a single bidirectional Group Terminal Block using all 16 Groups.
Multiple Function Blocks can exist in that Group Terminal Block without conflict. In the USB Group Terminal
Block Descriptor, select a Protocol descriptor that supports 128 bit messages.

[Psychlist1972]

Refer to the following statements. Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol Document Version 1.1.1 Appendix I: Using USB MIDI Group Terminal Blocks and Function Blocks

One strategy to avoid this conflict is to declare a single bidirectional Group Terminal Block using all 16 Groups.
Multiple Function Blocks can exist in that Group Terminal Block without conflict. In the USB Group Terminal
Block Descriptor, select a Protocol descriptor that supports 128 bit messages.

Right! I completely forgot about that scenario, and I was one of the ones pushing for group terminal blocks to be set up that way to avoid conflicts with function blocks.

The reason it hasn't come up lately, is devices usually declare function blocks afterwards, and we recalculate the ports when we receive that info. I'll need to go back and fix the code for this part. Definitely a bug in the naming code.

Thanks.

Pete