midici

Rust MIDI-CI / Property Exchange responder stack — the control plane for MIDI 2.0.

# 1. Build the virtual responder
cargo build -p virtual-responder --release

# 2. Run it (creates a virtual ALSA UMP endpoint)
cargo run -p virtual-responder --release -- --device-name midici --endpoint-name midici-responder -v 1

# 3. In another terminal, list endpoints
aseqdump -l

# 4. Monitor traffic (replace <client:port> from step 3)
aseqdump -u 2 -p <client:port>

The responder implements Discovery, PE Capabilities, Get, Set, Subscribe, Notify fan-out, ACK/NAK, MUID lifecycle, and Invalidate MUID — MIDI-CI v1.2 Management plus Property Exchange per M2-101/M2-103.

clap-autoprop demonstrates why this stack exists: a CLAP plugin whose parameters auto-appear as MIDI-CI Property Exchange data — zero manual MIDI-learn:

1. Controller/host does Discovery → PE Get ResourceList → Get ChCtrlList (the controller list resource) → auto-maps knobs
2. Controller subscribes to the resource (0x38 command: "start")
3. When the host flushes a param change, the plugin's control thread calls clap_autoprop::flush_param_change(engine, "ChCtrlList", partial_json), which fans out a command: "partial" update to every subscribed peer — the audio thread never touches the engine

The CLAP event bridge (RT ring + host-timer glue) and the full plugin binary land with the Phase-6/8 transport work; the PE subscription plumbing they will drive is complete and tested at the wire level.

See docs/guide/integrating-a-clap-plugin.md for the full walkthrough.

Asciinema recording of the autoprop demo — pending (HUMAN GATE G9a). Recording goes to docs/media/autoprop.cast; this link will be added once the file exists.

┌────────────────────────────────────────────────────────┐
│  Application (plugin params, device model, resources)  │
├────────────────────────────────────────────────────────┤
│  midici-responder      poll(now) / feed() / drain()    │
├──────────────────────┬─────────────────────────────────┤
│  midici-core         │  midici-pe                      │
│  Discovery, MUID,    │  Chunker/Reassembler, Mcoded7,  │
│  ACK/NAK, tx mgr     │  Resource registry, Subs        │
├──────────────────────┴─────────────────────────────────┤
│  midi2 crate (SysEx7 / UMP message types)              │
├────────────────────────────────────────────────────────┤
│  Transport adapters: ALSA UMP · CLAP events · (CoreMIDI│
│  / Windows MIDI Services later)                        │
└────────────────────────────────────────────────────────┘

Sans-io core — zero I/O, deterministic, no_std + alloc capable. Transport adapters are thin.

Audio thread does exactly one thing: move bytes.

• CLAP RT side: copies inbound SysEx bytes into wait-free SPSC ring, pops outbound ring, emits CLAP MIDI events. No parsing, no JSON, no allocation, no locks, no logging.
• Control thread: 10 ms timer drives poll(), drains rings, runs all state machines + JSON.
• Reassembly buffers: pre-reserved, capped at 64 KiB per (peer, requestId), max 4 concurrent per peer, LRU-evicted on 3 s timeout.
• Verified: assert_no_alloc on RT path in debug; loom/miri pass on ring wrapper.

• Architecture
• Integrating a CLAP plugin
• Writing a transport
• RT Contract
• Spec Coverage

Rust 1.97.1 (pinned in rust-toolchain.toml).

MIT. See LICENSE.