MIDI Monitor — see every byte on the bus
The MIDI Devices panel has a MONITOR section: a live, decoded tail of every MIDI message crossing the bus — hardware inputs and internal sources (Sequencer, Keyboard, Pads) alike, captured before any routing or filtering. That last part is the point: the monitor answers "is anything arriving at all?" even when nothing is routed anywhere yet.
Each row reads source · channel · type · detail:
Pads ch1 NOTE ON C2 (36) vel 110
BeatStep ch10 CC CC 74 = 82
sequencer ch8 NOTE OFF A3 (57)
- Pause (⏸) freezes capture while you read; clear (🗑) empties the tail.
- The list follows the newest entry; scroll up to read history and it stops following until you return to the bottom.
- Clock streams never appear as rows. A master sending MIDI clock produces 48+ messages per second — as rows they would flood the list instantly. They aggregate into a per-source rate line instead ("realtime ~48/s"), which doubles as a live "the clock source is alive" indicator.
The debugging recipe
"My controller does nothing" always splits into two halves, and the monitor tells you which one you're in:
- No bytes in the monitor → the problem is upstream: cable, port, device off, wrong virtual-MIDI port, notes outside the current pad bank.
- Bytes present but nothing reacts → the problem is downstream: missing Patchbay route, receiver filtering a different channel, a binding on the wrong note number, a
midi_ccnode listening to a different CC.
The assistant can run the same triage without screenshots:
For AI & automation · MCP
midi.monitor.get { limit? } — returns the tail as text, newest last. midi.ports.list says which ports the browser actually handed over.
The third case: a note that will not stop
Bytes arrived, something reacted, and now it will not let go — the controller was unplugged mid-note, the device was switched off, a sequencer stopped between note-on and note-off. No amount of routing fixes that: the note-off simply never happened.
Panic is the answer — the button at the right end of the transport strip, or the action:
For AI & automation · MCP
midi.panic {} — every routed instrument sink releases its voices and gates (poly and mono alike), and every hardware MIDI output gets All-Sound-Off + All-Notes-Off on all 16 channels. It reports how many sinks and outputs were told.
Two things happen on their own and are worth knowing so you do not go looking for them: unplugging a MIDI input releases the sinks that input was feeding, and switching project, restarting the audio engine or closing to the picker runs the same panic before the renderer goes away — otherwise external gear would keep holding whatever was sounding. keyboard.notes.clear is not this: it releases only what the on-screen keyboard holds.
What it deliberately does not show
Sub-millisecond timing (use the clock-follow diagnostics for that), SysEx payload contents (length only), and per-sink delivery — the monitor taps the bus before fan-out, so a row proves arrival at FaustWave, not arrival at a specific instrument. For per-receiver questions, check the route's enabled flag and the receiver's channel/CC configuration.