Notifications
Clear all
Developers & MIDI 2.0 Specifications
2
Posts
2
Users
0
Reactions
3
Views
Topic starter
I've been building a USB MIDI 2.0 8-port DIN interface on an RP2040 and have gotten it enumerating correctly on Linux (kernel 6.17) as a UMP Streaming device (ALSA leaves the JR clock handling to the application). On macOS (Tahoe) isn't CoreMidi supposed to handle the JR timestamps/clocks?
The device: A translator/interface - USB MIDI 2.0 on one side, 8 physical DIN MIDI 1.0 ports on the other. The DIN ports carry MIDI 1.0 content, so the Function Block midiProtocol is correctly set to 0x01.
What works on macOS: After several rounds of descriptor fixes (IAD triplet, CS_INTERFACE GTB type, MS Header in alt-0, UAC 1.0 AC header format), AppleMIDIUSBDriver binds correctly and MIDIServer enumerates the device as a UMP device. MIDIServer logs confirm it reads gtb.midiProtocol=0x2 from the inline GTBs in alt-1. UMP Endpoint Discovery completes successfully.
The problem: macOS only ever negotiates MIDI-1UP - it sends a Stream Config Request with protocol=0x01 and does not accept counter-proposals for protocol=0x02. The device appears in CoreMIDI as a standard MIDI 1.0 device. JR Timestamps/clocks are never send from the host.
What I've tried:
Setting bMIDIProtocol=0x02 in inline GTB descriptors (macOS reads it correctly but still negotiates 0x01)
Announcing midi1=true, midi2=true in Endpoint Info (no change)
Announcing midi1=false, midi2=true (device disappears from CoreMIDI - macOS apparently requires midi1 support)
Counter-proposing protocol=0x02 in Stream Config Notification (macOS ignores it and resends the 0x01 request)
The conclusion from MIDIServer logs is that configureDeviceUsingPortMap makes a hardcoded decision - seemingly based on the Function Block midiProtocol field - regardless of what the Endpoint Info capability flags say.
The question:
Are JR Timestamps ever achievable on macOS for a translator device whose function blocks report midiProtocol=0x01? Or does macOS require midiProtocol=0x02 function blocks to offer MIDI-2UP negotiation?
If a device sets midiProtocol=0x02 on its function blocks (meaning it would present the DIN ports to the host as MIDI 2.0 channels), does macOS then negotiate MIDI-2UP and honour JR Timestamps?
Is there any MIDI-CI or UMP Stream exchange that can prompt macOS to switch to MIDI-2UP after initial enumeration?
And what is up with the phantom Midi 2 device with 0 ins/outs ?
Any insight from people who have shipped MIDI 2.0 devices that work under CoreMIDI would be very welcome.
Posted : 25/05/2026 2:14 am
Ok there is a bit to unpack here. If I understand correctly, you want to run 8 MIDI 1.0 DIN ports over a UMP (USB MIDI 2.0) device - and send JR Timestamp messages? Or Receive JR Timestamp? I don't believe any of the OS currently doing anything with JR Timestampls except pass them on - but more on that later...
I am going to make some suggestions - excuse me if I suggest things you have already done.
Setting aside the JR Timestamp issue. If you want CoreMIDI to work better (in your use case) you are better off using Group Terminal Blocks. I would suggest one GTB for MIDI 1.0 pair. eg. DIN 1 I/O on Group 0, DIN 2 on Group 1 etc. Set the bMIDIProtocol in the USB descriptor to 0x03 - this declares MIDI 1.0, but still accept 128bit messages. There is no need to upscale the messages from MT2 (MIDI 1.0 CVM) to MT4 (MIDI 2.0 CVM) - it will provide no benefit, and can in some case cause issues.
Still report the Endpoint, and FB stream messages matching the GTB settings.
This means that the DIN ports will appear as MIDI 1.0 src/dest in Mac, while the "MIDI 2.0" src dest will recieve all messages JR Messages (and all the MT2 messages from the other Groups)
What MacOS are you aiming for? - earlier versions do some strange things with mixing MIDI 1.0 and MIDI 2.0 protocols.
Posted : 25/05/2026 5:54 pm