You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This device is likely not supported. Can you compare it's USB IDs to the known devices? If it's not listed yet, please let us know so we can document it.
Not in the known-devices table yet. Also doc/USB.mdrl doesn't exist on master — I assume you meant doc/USB.md.
Root cause of No device found is the PID whitelist in src/com/ConnectionFactory.cpp:37-48, which ends up as throw CommunicationException{"No device found"} at src/com/ConnectionFactory.cpp:90. But adding 0x003a would not be enough: the MM+ exposes no vendor-specific, HID or MIDI interface over USB. The only configuration is USB Audio class:
1 config, bNumInterfaces 3, bmAttributes 0x80
IF0 alt0 Audio / Control Device 0 EPs iInterface 16
IF1 alt0 Audio / Streaming 0 EPs
IF1 alt1 Audio / Streaming 1 EP 0x81 IN iso, wMaxPacketSize 0x0126 (294 B)
IF2 alt0 Audio / Streaming 0 EPs
IF2 alt1 Audio / Streaming 2 EPs 0x01 OUT iso, 0x0128 (296 B) | 0x82 IN iso, 3 B (feedback)
Formats: 2 ch / 3-byte subframe / 24 bit / 48 kHz (bSamFreqType 1 Discrete, tSamFreq 48000)
Terminals: T1 Line Connector in (2 ch), T2/T3 USB Streaming, T4 Line Connector out
All three interfaces bind to snd-usb-audio (/proc/asound/cards → 5 [Plus]: USB-Audio - Mustang Micro Plus at usb-0000:11:00.0-4.1, full speed). So over USB it is a plain class-compliant audio interface — amp tone out, mono in, plus a small feedback endpoint. None of the endpoints UsbComm writes to exist here, so a PID-only change cannot work; it would need a second, different transport.
Control is exposed over BLE GATT instead (that is what the Fender Tone app uses). I captured an HCI/btsnoop log of the Tone app ↔ device session (Android bugreport), first pass:
GATT services: 00001100-d102-11e1-9b23-00025b00a5a5 (handles 0x000c–0x0014) and 90559580-b707-11ee-acb1-7b7e30f1af54 (handles 0x0015–0x001b), plus the standard GAP/GATT services.
Write char 820a7e34-4e0a-4f90-8520-04ebce35a3a1 (handle 0x001b, Write Request), notify char 1017adcc-dcbc-4387-a59f-2546b2ea5bb0 (handle 0x0017), and a third characteristic with a CCCD in the first service.
MTU: client 128, device 517. Device is bonded and connected before the app-level exchange starts.
Session shape: ~1400 Write Requests on 0x001b, ~210 Handle Value Notifications on 0x0017.
First notifications carry the firmware version (1.0.29) and the factory preset-name list ("Driven Deluxe", "Stadium Lead", "Swirling Echoes", "Metal 2000", …). Payloads look protobuf-ish, e.g. 35 00 0e 12 0c 08 02 32 08 0a 06 "1.0.29".
Happy to write the protocol up in more detail, or dig further, if a BLE transport is something you would consider for this device.
Activity
offa commentedon Oct 18, 2026
This device is likely not supported. Can you compare it's USB IDs to the known devices? If it's not listed yet, please let us know so we can document it.
Selene0623 commentedon Oct 18, 2026
I will do that. I can also try to help RE the devices protocol while we're at it.
Selene0623 commentedon Oct 18, 2026
USB IDs of the Mustang Micro Plus, measured on CachyOS (kernel 7.2.10):
Not in the known-devices table yet. Also
doc/USB.mdrldoesn't exist on master — I assume you meantdoc/USB.md.Root cause of No device found is the PID whitelist in
src/com/ConnectionFactory.cpp:37-48, which ends up asthrow CommunicationException{"No device found"}atsrc/com/ConnectionFactory.cpp:90. But adding0x003awould not be enough: the MM+ exposes no vendor-specific, HID or MIDI interface over USB. The only configuration is USB Audio class:All three interfaces bind to
snd-usb-audio(/proc/asound/cards→5 [Plus]: USB-Audio - Mustang Micro Plus at usb-0000:11:00.0-4.1, full speed). So over USB it is a plain class-compliant audio interface — amp tone out, mono in, plus a small feedback endpoint. None of the endpointsUsbCommwrites to exist here, so a PID-only change cannot work; it would need a second, different transport.Control is exposed over BLE GATT instead (that is what the Fender Tone app uses). I captured an HCI/btsnoop log of the Tone app ↔ device session (Android bugreport), first pass:
00001100-d102-11e1-9b23-00025b00a5a5(handles 0x000c–0x0014) and90559580-b707-11ee-acb1-7b7e30f1af54(handles 0x0015–0x001b), plus the standard GAP/GATT services.820a7e34-4e0a-4f90-8520-04ebce35a3a1(handle 0x001b, Write Request), notify char1017adcc-dcbc-4387-a59f-2546b2ea5bb0(handle 0x0017), and a third characteristic with a CCCD in the first service.1.0.29) and the factory preset-name list ("Driven Deluxe", "Stadium Lead", "Swirling Echoes", "Metal 2000", …). Payloads look protobuf-ish, e.g.35 00 0e 12 0c 08 02 32 08 0a 06 "1.0.29".Happy to write the protocol up in more detail, or dig further, if a BLE transport is something you would consider for this device.
offa commentedon Oct 19, 2026
Indeed a typo 😅. I've added the new device to the list.
As for other devices: If someone figures out the protocol and implements the necessary stuff, I'm happy to help within my possibilities.