[BUG][App Compat] Surge XT, which uses JUCE, has all inputs unclickable and disabled (possible JUCE compat)

[Psychlist1972]

Release Customer Preview 1, Canary 27788

Not sure where this error is from, but none of the MIDI inputs in this JUCE app can be enabled, despite being enumerated.

Surge XT author says that is regular JUCE code from their stand-alone app, not something specific to Surge XT.

[Psychlist1972]

Running it again and now the boxes can be checked. Talking to JUCE folks to obtain some insight into what enables or disables those boxes.

[reuk]

I can repro some similar behaviour in the JUCE AudioPluginDemo Standalone example that's available in the main JUCE repo.

Environment:

• Windows 11 canary 27788.1000
• ProtoZOA with v1.0 firmware: https://github.com/midi2-dev/AmeNote_Protozoa/releases/tag/V1.0
• JUCE 8 develop

Building the test app:

• Get the JUCE repo: git clone git@github.com:juce-framework/juce
• Configure the build (from the juce dir): cmake -B cmake-build-debug -D JUCE_BUILD_EXAMPLES=ON
• Build the app target: cmake --build cmake-build-debug --target AudioPluginDemo_Standalone

Observations:

• When I start the JUCE app with the ProtoZOA connected, the inputs are enumerated correctly in the settings screen.
• When I disconnect the ProtoZOA with the settings open, the list entries remain and can be highlighted but not selected.
• When I start the JUCE app with no device connected and then plug in the ProtoZOA, the MIDI device list remains empty.

Commentary:

• JUCE listens for WM_DEVICECHANGE messages sent to a hidden message window, and updates the MIDI device list after a short delay whenever any such message is received. The mechanism that achieves this can be found here. As far as I can tell, this works as expected and fires the callback to rescan devices when the ProtoZOA is connected/disconnected.
• When the ProtoZOA is initially disconnected, and is later connected, midiInGetNumDevs and midiOutGetNumDevs return 0. This explains why the JUCE device list doesn't get populated with new entries.
• When the ProtoZOA is initially connected, and is later removed, midiInGetNumDevs, midiOutGetNumDevs, midiInGetDevCaps, and midiOutGetDevCaps continue to report the ProtoZOA as present, even after a delay. Clicking on one of the checkboxes does attempt to call midiInOpen, but this fails with error 1 ("Undefined external error").

The JUCE code has worked up until now, so my impression is that the new backend has changed the behaviour of the classic MIDI API. There's a chance this is a bug in JUCE - maybe there's some call we should have been making to force an update of the MIDI device metadata? I don't see anything like that from skimming the API reference though.

I'd be interested to know whether this is the same behaviour that you're seeing, or whether I've discovered an unrelated issue.

Please let me know if there's any more information I can provide to help diagnose the problem.

[Psychlist1972]

Thanks, @reuk !

I assume that firmware rev is MIDI 2.0 / UMP, and that the driver loaded for it was the usbmidi2.sys driver (the ACX driver). Can you confirm?

I'm not sure if this is the same issue or not, but I appreciate the repro steps (especially for building the JUCE demo). We will look into it.

[reuk]

I assume that firmware rev is MIDI 2.0 / UMP

I believe so, I'm using the UUT_USB_FB.uf2 firmware from the public releases page

the driver loaded for it was the usbmidi2.sys driver (the ACX driver)

Yes, Device Manager shows only "ksthunk.sys" and "USBMidi2.sys" in the Driver File Details window for the ProtoZOA (named "MSynthl" due to the loaded firmware).

I've also got a CME U2MIDI Pro (MIDI 1.0 1-in 1-out USB class-compliant), and that behaves in a similar way, where the device list doesn't update properly when the device is connected or disconnected.

Please let me know how you get on with the investigation.

[Psychlist1972]

This appears to have been due to our port numbering. I have this running correctly in internal builds. Thanks!

[Psychlist1972]

Fixed in Customer Preview 2 if you use the full GitHub install on Canary 27802