macos: fix command8-mackie's sudo requirement at launch (partial); verify reaper/monitor - #3
Merged
Merged
Conversation
…ckie command8-mackie constructed MackieBackend (which creates RtMidi/CoreMIDI virtual ports) before ever opening the UsbSurface. On macOS, merely initializing an RtMidi client -- even just to publish unrelated virtual ports -- causes this process's own future libusb claims of the Command|8 to race CoreMIDI's in-process device-notification handling for the same malformed MIDIStreaming interface, and lose (LIBUSB_ERROR_ACCESS), requiring sudo. Reordering startup so the Surface is claimed first (macOS only; Linux and Windows don't share this problem and keep the original fail-fast order) makes first launch sudo-free, verified on hardware. This is a partial fix, not a full one. Once RtMidi has ever been constructed in-process, a claim lost to a later unplug cannot be regained from that process without root -- verified on hardware, including that this doesn't resolve with more retries/time and that tearing down and rebuilding the CoreMIDI client around the reclaim attempt doesn't help either. Documented in both the code comment and the README rather than papered over: replug-while-running still needs sudo for command8-mackie specifically. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
alphonsom added a commit
that referenced
this pull request
Aug 10, 2026
Brings in the macOS work and meter ballistics merged via PRs #1-#3. Clean merge, no conflicts; builds with no warnings and all three tests pass. README: Windows no longer requires Digidesign/Avid's driver. The dongle makes the surface enumerate as an ordinary class-compliant USB-MIDI device with no driver at all, and the ports look the same to this engine either way. Also spells out the exclusive-access trap, which is easy to hit and gives no useful error: a DAW holding the Command|8 ports stops the engine opening the device. The DAW talks to the engine over OSC or the MCU loopback pair, never to the surface directly -- the Command|8 speaks a proprietary protocol, so a DAW sending it generic MIDI just twitches the faders and leaves the display Offline, which is exactly what a first Windows attempt looks like. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
command8-mackieconstructedMackieBackend(which creates RtMidi/CoreMIDI virtual ports) before ever opening theUsbSurface. On macOS, merely initializing an RtMidi client — even just to publish unrelated virtual ports — causes that process's own future libusb claims of the Command|8 to race CoreMIDI's in-process device-notification handling for the same (malformed) MIDIStreaming interface, and lose (LIBUSB_ERROR_ACCESS), forcingsudo.command8-mackie's startup (macOS only — Linux/Windows don't share this problem and keep their original fail-fast order) so theUsbSurfaceis claimed beforeMackieBackend/RtMidi is constructed. Verified on hardware: first launch is nowsudo-free.command8-monitor/command8-reaperverified clean: neither ever touches RtMidi/CoreMIDI.command8-monitorclaims the interface and gets live fader/encoder input + LED feedback unprivileged.command8-reaperdoes the same and was directly re-tested reclaiming the interface unprivileged after a live unplug/replug cycle (not inferred from shared code shape — actually re-run).Testing (macOS 15.6, Intel, Homebrew, libusb 1.0.30)
cmake -B build -G Ninja && cmake --build build): clean, zero warnings.ctest: 3/3 pass (protocol,feedback,usb_packets) after every change in this branch.command8-mackie: first launch confirmed unprivileged (nosudo) both before and after the fix was re-verified; replug still requiressudo, confirmed via a 35+ second observation window (steady failure, not a resolving race) and via a failed tear-down/rebuild mitigation attempt (reverted).command8-reaper: confirmed unprivileged on first launch, and confirmed unprivileged reclaim after a live unplug/replug cycle.command8-monitor: confirmed unprivileged fader/encoder input and select/mute/solo LED feedback on real hardware.🤖 Generated with Claude Code