feat(surface): the LCXL3 bench — a place to look at the new device before trusting it
Not an extension of lcxl-leds.py, deliberately. v2 and v3 are different protocols, not different constants: v2 is a template/palette SysEx driving 3-colour buttons, v3 has true RGB per control, a 128x64 OLED, endless encoders, and a CC map that only exists in DAW mode. Folding v3 in would produce a file that lies about both. When the numbering settles, lcxl_grid.py stays the one authored table and this becomes its transport. Every byte sequence in here is quoted from the official programmer's reference v1.0, not recalled — RGB is 01h 53h <idx> <R> <G> <B>, the bitmap is 09h with 1216 bytes and a 7Fh terminator rather than F7h, and the feature CCs live on channel 7 of the DAW in port. Transport is python-rtmidi via mido rather than shelling out. aseqsend on this system takes -s as a FILENAME: `aseqsend -p 20:0 -s "B0 25 05"` prints 'cannot open B0 25 05' and exits 0. A silent no-op, which is how a first paint attempt can look like a hardware answer. lcxl-leds.py shells out that way today, which is worth revisiting. The subcommand that matters is `keystone`. The guide files 'Colouring the surface' and 'Controlling the screen' inside the DAW mode chapter, prefaced 'only available once DAW mode is enabled'. If that is how the document is organised rather than a hardware restriction, paint works in standalone and the corpus keeps its v2 numbering — a 169-file difference. So it gets tested in three steps with PLN's eyes on the surface, not assumed either way. `sweep` exists for the same reason: the DAW-mode index map is a low-resolution diagram in the PDF, so we light each index in turn and read the map off the hardware.
Showing
tools/lcxl3.py
0 → 100644
Please
register
or
sign in
to comment