macOS support (libusb Surface + virtual CoreMIDI), and meter falloff on all platforms

[alphonsom]

Brings the engine to macOS, and fixes two meter bugs that turned out to affect every platform.

Verified on hardware: a Command|8 driven from Reaper's native Mackie Control on macOS — faders bidirectional (10-bit in, motorised out), pan encoders, encoder rings, meters, LCD, buttons and LEDs.

macOS backend

The malformed MIDIStreaming input descriptor needs a different workaround per platform:

	getting the input	MCU bridge needs
Linux	snd-usb-audio quirk	snd-virmidi
Windows	Digidesign/Avid's driver	a loopback pair
macOS	claim the interface (libusb)	nothing

CoreMIDI has no quirk mechanism, so the device's ports enumerate but stay inert and no MIDI-API backend can reach the input. MacosSurface bypasses CoreMIDI on the device side and speaks USB-MIDI packets over libusb, matching VID/PID 0dba:8000 instead of a port name.

MacosMidiPort goes the other way. macOS is the only supported platform where an application can create MIDI endpoints, so the MCU side publishes its own virtual source and destination — no loopback utility. Both endpoints matter: with only a source, a DAW sees an input with no matching output and control-surface support reports it cannot find a MIDI output.

src/protocol, src/feedback, src/controller and both front-ends are untouched.

Root is required

Claiming the interface takes it from CoreMIDI's class driver, and CoreMIDI reclaims it the moment anything releases it. Unprivileged processes cannot even enumerate the device, so "absent" and "not permitted" are indistinguishable — open() reports both possibilities rather than guessing. The README covers this and why the alternatives (unloading the system driver, a codeless kext, DriverKit) are worse for a self-hosted tool.

Meter fixes (all platforms)

Meters never fell.meter() sent the host value and nothing more, so the display froze on the last value and stayed lit after playback stopped. Hosts transmit meter values sparsely — Reaper only when the quantised 0-12 level changes, ~1 Hz measured — and expect the surface to supply ballistics, as real MCU hardware does in firmware. The value is now a peak: instant rise, decay from Feedback::tick(). Default 1200 ms, chosen against captured Reaper traffic; set_meter_decay_ms(0) disables it.

Levels were mis-scaled.static_cast<int>(v * METER_ROWS) truncates, so 11/12 of full scale lit 5 of 6 LEDs and anything below 1/6 read as silence. Now rounds, with any non-zero signal lighting at least one LED.

Unchanged rows are no longer re-sent.

Testing

tests/test_feedback.cpp (new, wired into CTest) covers both fixes against a recording fake Surface, including the original symptom: full scale, then ticks with no host updates, asserting it reaches zero. Both suites pass; clean build, no new warnings.

Reviewer notes

• Not built or run on Linux or Windows. The meter change is cross-platform and deserves a check on at least one of them. The macOS files are APPLE-guarded, but feedback.{hpp,cpp} and controller.cpp are shared.
• With falloff active, a peak landing exactly on a half-row boundary renders one row low — decay elapses before the tick reads it. Sub-LED, at exact boundaries only; the rounding tests disable decay to isolate the behaviours.
• The __APPLE__ branch for default MCU port names is a real fix, not cosmetic: the generic non-Windows default "VirMIDI" is a Linux virmidi name and wrong for ports we create ourselves.
• docs/PROTOCOL.md is unchanged — no new protocol findings; this port was built against it and independently confirmed the wake handshake, 10-bit faders and (note, subid) button identity on hardware.

🤖 Generated with Claude Code