JUCE 8.0.11 MIDI PORT NAME

General JUCE discussion
1

Compared to JUCE 8.0.10, this version completely changes the naming of MIDI ports. For example:

Array<MidiDeviceInfo> itemsIn = MidiInput::getAvailableDevices();

for (const auto& item : itemsIn)
{
    DBG(item.name);
}

Previously the device was listed as “MY PORT”, but now it appears as “MY : PORT”.

Does anyone know why? Is this a JUCE-introduced bug, maybe related to MIDI 2.0 compatibility?

I can confirm that the colon is added only for MIDI 2.0 devices.

3

Please could you let us know which platform you’re using for testing (macOS/Windows/Linux/etc.) and details of the actual device (physical or virtual) that you’re scanning?

If you’re on Windows, are you using the new Windows MIDI Services, or WinRT Midi, or legacy Win32 Midi?

4

I’m testing on macOS and this affects only the physical devices. The virtual ones seem to be shown as expected.

5

What MIDI hardware are you connecting?

Which version of macOS are you running, and which Xcode version are you using to build your application?

6

I’m connecting Studiologic SL 88 (MK2) and Roland MIDI 2.0

7

Which version of macOS are you running, and which Xcode version are you using to build your application?

8

macOS 26.1

xCode 26.1.1 (17B100)

9

Possibly related: Supperware head trackers that use the JUCE APIs to get head pose data over MIDI are no longer working with JUCE 8.0.11; reverting back to JUCE 8.0.10 makes everything work again. This is on macOS 15.7.2; Xcode 16.2.

11

Thanks for reporting. We’ve updated the naming scheme here, so it should be closer to the old naming:

We haven’t been able to test the issue with Supperware head trackers. If you’re able, please update to the latest version of the develop branch and check whether the issue is resolved by the naming change. Otherwise, we’ll need some more information in order to continue investigating.

12

Thanks @reuk for the update. I’ve tested the latest develop with the Supperware tracker, including a recent change that was pushed onto the supperware git repo ( GitHub - Supperware/ht-api-juce: Head Tracker API for C++/JUCE ). but unfortunately the tracker still doesn’t seem to be able to connect over MIDI.

13

It turns out this is a separate issue related to the use of Universal MIDI packets. The problem is summarised here, in case anybody else experiences similar difficulty with the head tracker or other products.

In its support of for Universal MIDI Packets and MIDI 2 (which JUCE has been rewritten to use internally) Apple has reinstated use of the 0x0F-type USB MIDI message. This type of message, for sending unassociated single bytes of data, is one I haven’t otherwise seen in the wild, under any operating system, since about 2008. As nobody used it for formatted packets anymore, I didn’t bother including it in my drivers (how do you test against data that never occurs?)

Now it’s back and it requires a firmware tweak before JUCE 8.0.11 breaks people’s builds, which I’ll be pushing to all users in January 2026. Other equipment built on newer driver stacks may also have this problem.

2 Likes
14

In my experience, they not only reinstated the 0x0F type byte, but also placed it incorrectly. I am encountering this issue with a 21-byte SysEx message sent from a JUCE 8.0.12 application on Sequoia 15.3.1 to my hardware.
This does not occur with JUCE 8.0.8. I did not test the intermediate versions.

The first two packets (the first six bytes of the SysEx message) have the correct 0x04 type byte. However, the third packet has a 0x0F type byte and contains only the 9th byte, followed by two zero bytes. The fourth packet then reverts to a 0x04 type byte and contains the 10th, 11th, and 12th bytes.

This behavior clearly breaks the SysEx message.

15

It’s not great, but it’s now our problem. This was the way I remember things briefly to have worked in around 2008-9 when Novation (where I was employed) was developing new firmware for the STM32 and we were rolling our own USB stack.

I’d presumed (as had, no doubt, the authors of the USB MIDI spec) that the 0xF message was to let DIN interfaces relay deliberately broken or strangely-timed data just so that they could, and I agree that this feels like an abuse of the protocol.

The head tracker handles only SysEx so incorporating this is a quick fix. If you’re making an instrument, the only way around it is to build the DIN MIDI parser into the USB stack which does feel broken. The whole point of the context preamble was to simplify parsing. Still, we are where we are.

16

I don’t know if I fully understand your answer, and if not I apologize in advance, but i’m not talking about 0x0F types in general: i’m experiencing a 0x0F code where a 0x04 should be.
I mean literally breaking a sysex in half including one of its bytes (the 9nth) in a 0x0F type packet, and then continue with 0x04 packets, thus shifting all the rest of the packets of one byte respect what they should be and breaking the recieving state-machine status.
From my point of view this is not an abuse of the protocol but a violation of it, or, in my opinion, a bug.

18

Just to clarify, are all the bytes getting to the receiver in the correct order?

It’s not clear to me from the USB MIDI spec whether it’s allowed to use 0xf packets to continue SysEx messages. The wording doesn’t rule it out, so I suppose if there’s a SysEx in progress and an 0xf packet is received, the best you can do is to append the contained byte to the incoming sysex payload.

I’m interested to know exactly why this is only now becoming an issue. Although quite a lot of the MIDI handling code changed between JUCE 8.0.8 and 8.0.12, we’re still calling through to the same system API as before (MIDISendEventList).

The main difference, as far as I can tell, is that previously we would only send a single MIDIEventList for a short sysex like this:

The full bytestream message gets passed to newSendImpl, and then this is converted to UMP internally and all UMPs are added to the same MIDIEventList before sending it.

In the new implementation, the conversion from bytestream to UMP happens at a higher level, so we end up calling send() once for each UMP, which in turn creates a separate MIDIEventList for each UMP:

I don’t know if this is definitely the cause of the change (I can’t easily verify, as I’m not sure how to sniff USB traffic on macOS - seems it might not be possible without disabling System Integrity Protection). If you’re in a position to log USB traffic, it might be interesting to try modifying the CoreMIDI code in 8.0.8 to send a new MIDIEventList for each UMP to see whether that also results in 0xf packets being added. If we know the cause of the new behaviour, then we will be better placed to decide whether we need to make a change in JUCE, and what that change should be.

19

Yes, bytes are in the correct order.
You are actually right… I’ve read the USB MIDI1.0 documentation again and it is not clear whether it’s allowed to use 0xF packets to continue SysEx messages.
It is stated that they can be used to avoid USB MIDI parsing, but I would expect this to imply that an entire message should be sent byte per byte with 0xF packets.
To me breaking an USB MIDI parsed SysEx with a single non-parsed byte still make no sense, but, again, it’s true that it is not ruled out.

I’ve disabled System Integrity Protection on my Mac and using Wireshark to log USB traffic, so i’m able to perform the test you suggested… i’ll get back with the result as soon as I’m able to do it.

Thanks!!

20

Hello Reuk,
I’ve managed to experiment with your suggestions and the problem arise exactly as you expected.
Letting the send happen on every ump::View and re-init the MIDIEventList after every send, ends up introducing the 0xF packet again.

It seem to always end up being the third one if more than 6 bytes are sent, no matter how many more.
So you end with two 0x4 packets, one 0xF, and all the 0x4 packet needed plus the sysex end one (or just this if it’s enough).
The same was also for my first captures.

Let me know if you are planning to fix this.
Thanks.

21

We’ve pushed an update in this area:

This will now mean that short sysex MidiMessages will now be sent in a smaller number of MIDIEventLists, each of which is larger than before. I expect this to go some way toward resolving the issue you were seeing, but I don’t think there’s anything we can do to completely avoid continuation packets being sent. I expect that the OS may reintroduce continuation packets for sysex messages longer than a single MIDIEventList, so it’s probably still a good idea to ensure that USB devices can handle continuation packets during sysex transfers.