Verify the routing source codes and model the grid's initial state

[baakhoff]

The routing window writes source codes (entity 0x33, selector 0x06) inherited from upstream that have never been verified here by write-and-observe. And since reads stall or alias (docs/PROTOCOL.md), the grid cannot show actual state either — the exact complaint in TheOnlyJoey#11, where the grid starts all gray, gains blue dots on click, and can never be cleared or trusted.

• Verify each destination/source code on the iD24 by ear or loopback, and fix the table where it is wrong.
• Model the power-on defaults so the grid starts truthful instead of gray, and add a way to return to them (pairs with the state persistence in Save and restore mixer state across restarts #5).
• Related unknowns from upstream worth settling with the same test session: whether output 3/4 and the digital outs are fully covered (Figure out output 3/4 and Digital Out's TheOnlyJoey/MixiD#3), and whether the insert/send-return path has any digital control at all (Do send/returns have any digital control? TheOnlyJoey/MixiD#5) — the iD24 on hand has two inserts, so both are testable.

[baakhoff]

Progress. The analog side (outputs 0..5) is now verified on hardware and shipped in 6850f39..6b8bae6:

source	codes (L/R of the pair)	notes
Main mix	0x25 / 0x26	this is the monitor section's feed: knob, Dim and Cut apply on any output carrying it, phones included — heard directly
Alt	0x1e / 0x1f	live with the Alt switch, verified with speakers on outs 3/4
Cue B	0x20 / 0x21	the decode had the cues the other way round; caught by ear
Cue A	0x22 / 0x23
DAW direct	output's own index	fixed full level, bypasses the monitor section

The window now routes per output pair, starts from modelled defaults (1+2 Main, 3+4 Alt, phones Cue A), pushes routing on connect — which also heals a device left mis-routed — and has a reset button. Details in docs/PROTOCOL.md.

Still open here: the digital outputs (routing channels 8..11) have never been written to, and whether the insert/send-return path has any digital control (TheOnlyJoey#5) is still unknown.

[baakhoff]

Two updates from reading Monix's decompile notes against our hardware results, now recorded in docs/PROTOCOL.md (16ce5b9):

• Their "corrected" routing formula places the second cue at 0x22/0x23 and reads 0x20/0x21 as cue A. Both disagree with this hardware: 0x22 is the code the left ear proved unusable (a stuck full-level feed nothing controls), and the 0x20/0x21 tap audibly carries the matrix's cue B cells. Notably their own raw capture of the official app recorded 0x23/0x24 — the capture agrees with our ears; their static formula does not. Our mapping stands.
• The digital output range narrows: outputs 8..9 are the optical pair, and 10..11 turned out to be the loopback pair (routed since 16ce5b9). So what remains of this issue's digital-out scope is just the optical pair's behaviour in ADAT mode, plus the insert path.

[baakhoff]

Parked, with the scope now fully mapped: the insert half is not applicable — inserts are an iD22 feature and the iD24 has no insert points. What remains is one experiment: whether the optical out pair (routing outputs 8/9) obeys the source codes, best proven with a TOSLINK cable looped from optical out to optical in, S/PDIF both ends, watching DIGI 1/2 carry whatever is routed there. A probe tool for it exists (probe optical ); waiting on a cable.