Read the rig position and the morph from the channels that carry them

[gotwalt]

Three bugs with one shape: a value the docs said was on the wire, that never actually arrived, so it silently never moved. Nothing errored — the value just sat still.

The rig position

docs/08 claimed the device announces every rig change as a Bank Select LSB plus a Program Change. It does not. A probe of the streaming session across nine rig changes yields zero non-SysEx bytes — which two other places in the same docs already said.

So current_bank / current_rig_slot froze at their connect-time seed, and MetersApp computed every move from a stale index 0. Every reported symptom follows from that one fact:

pressed	computed	why
Bank Up	0 → 5	stuck at 0, so always bank 2
Bank Up again	0 → 5	hence "can't go past bank 2"
Bank Down	0 → 0	swallowed by the target != current guard
Rig Up at bank 2	0 → 1	bank 1 rig 2

The position is on the stream, under an undocumented request function. $46 reads an extended address and the device answers $06 in ~20 ms — and pushes an unsolicited $06 for whichever of bank (100701) / slot (100702) changed on every rig change, front panel included. Below 16384 it answers in the $01 page/number form instead, mirroring how $47 degrades to $03. The CC32+PC parsing is gone along with its vectors.

The morph

Tracked at page 0 / $0B, taken from a third-party mapping and never validated. $0B is a real address that answers a request with a constant 0 whether the rig is morphed or at base, and is never pushed — a client keyed on it looks like a rig that is never morphed.

The morph is two addresses: $77 (119) the position, $50 (80) the button, momentary. Each language carries a regression test asserting $0B moves nothing. The PySwitch attribution in CREDITS.md and docs/09 is corrected, since that address came from there.

The position is CBOR-only and push-only — neither $41 nor $46 draws a reply, and it never appears on the MIDI3 stream — so StateSnapshot reads it from the state dump and a new live CborSession streams it.

Both channels at once

Neither channel is a superset. Measured with both open across the same gestures:

	MIDI3	CBOR
Meter block (11 values)	all eleven	one — the tuner strobe phase
Morph position (119)	never	pushed, ~40 Hz while ramping
Morph button ($00/$50)	pushed	never
Session-open state dump	none	~1174 addresses

The device tolerates concurrent read-only sessions — its fragility is connection churn, not concurrency — so a client that wants the whole device holds both. DeviceState::apply_cbor folds a CBOR value into the same fields and events as apply; DeviceModel::apply_cbor is the seam a client pipes the second channel through. All three languages.

MetersApp

Holds both sockets, shows the morph position live, and can toggle it — CC 11, which names a destination, rather than CC 80, which ramps over two seconds and alternates direction per press. It no longer pre-fetches the CBOR snapshot to learn its position; $46 does that on the session it already has, removing a fragile connection and ~1.3 s from every connect.

Navigation is now serialized behind a settle gate. Two rig loads issued 8 ms apart are answered normally and then kill the device ~20 seconds later, costing a power cycle — the fuse being delayed means nothing in the response says harm was done. One move at a time, the load left alone before its read-back follows, so a burst of taps costs two loads however long it is.

Also a loopback command socket (KP_DEBUG_PORT, off by default, binds 127.0.0.1) that drives the navigator and dumps the store's position — how all of the below was verified.

Docs

New docs/11-channels-and-data-paths.md compares the two channels and lists what a holistic pass should resolve. It also fixes a framing trap: "CBOR vs MIDI3 vs SysEx" is three things but there are two channels — SysEx is the payload language inside MIDI3 framing, and that conflation is exactly what produced the position bug.

Three places said concurrent sessions were unsafe (docs/01's "only one controller may hold a session at a time", docs/06, and the Python fetch_state_snapshot docstring). All now distinguish concurrency (fine) from churn (fatal).

Spec 0.5.0 → 0.6.0: function $46, the morph addresses, morph_address.

Verification

Against hardware, not just tests: the originally reported sequence; bursts of 2, 3 and 10 rapid taps (each followed by a full delayed-fuse wait, zero drops); a rapid Bank Up + slot tap landing in the new bank; morph on/off; and both channels held open together without a drop.

All three suites green — 381 Python, 105 Rust, 98 Swift — plus lint, format, and the codegen/vector drift checks.

Worth a second look

The amp page $0A is absent from the CBOR dump while every neighbouring page is present. One observation, one device (a Player), one firmware — flagged in docs/11 rather than asserted.

🤖 Generated with Claude Code

https://claude.ai/code/session_013XSn94RpApv9AYMQABGM8S