Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
  • This project
    • Loading...
  • Sign in / Register
T
Tidal
  • Overview
    • Overview
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • PLN
  • Tidal
  • Repository

Switch branch/tag
  • Tidal
  • tools
  • lcxl3-probe-display.py
Find file
BlameHistoryPermalink
  • PLN (Algolia)'s avatar
    feat(lcxl3): a probe that asks the device instead of us guessing · ac864787
    Three rounds of screen fixes were hypotheses dressed as patches: the lap clock
    is frozen at 0:00 on glass while our ghost ticks, and the DJF Hz readout
    "refresh maybe every 1s, not smooth at all". Both point at one unproven rule —
    that a field write to an ALREADY-VISIBLE display target does not repaint
    without a bring-up — and the protocol offers no display readback, so the only
    instrument that can settle it is PLN's eyes, asked precise questions in order.
    
    So: a guided probe. Each step prints an instruction, sends a minimal
    distinguishing sequence, and records what he saw; the run ends with a table and
    a verdict naming the surviving hypothesis, plus JSON in the scratchpad so the
    answers outlive the session. --dry-run prints every byte with the hypothesis it
    tests, so the whole thing is reviewable without hardware.
    
    It distinguishes: bring-up NONE/AFTER/BEFORE/RECONFIG on the stationary target;
    the same on the temporary target plus a 20/10/5-per-second rate ladder (which
    directly decides the DJF smoothness fix); whether per-control targets can be
    driven while untouched; which auto bit actually summons; and an arrangement
    census with a SENTINEL, so an arrangement the firmware IGNORES reads as "still
    the sentinel" instead of masquerading as a real layout — without that, "ignored"
    and "renders like the previous one" are the same observation and the census
    would invent arrangements that do not exist.
    
    Two things it found by reading our code, before touching the device. The
    targets showing both symptoms are on arrangement 2, not the 4 we describe in
    our own notes (4 is only label_control's default). And CFG_BRING_UP = 0x7F is
    arithmetically ARR_TRIGGER | AUTO_TOUCH | AUTO_CHANGE, so every bring-up may
    RE-ARM the auto-display bits we deliberately clear on the three DJF knobs —
    which would explain, mechanically, why the firmware's number keeps reappearing
    over "HPF 3.4kHz !!". That became its own probe step.
    
    Safety, since the rig is live: display and config SysEx only, enforced by an AST
    check that there are zero cc/note/rgb/feature call sites plus raisers installed
    over those methods at open time; it refuses to run while the driver is up
    (printing the pid, the kill, and the restart line); and it restores the
    arrangement the driver expects from a finally block.
    
    NOT YET RUN ON HARDWARE — committed so the work is not parked in a scratchpad.
    PLN (Algolia) authored Aug 29, 2026
    ac864787
lcxl3-probe-display.py 50.2 KB
EditWeb IDE
×

Replace lcxl3-probe-display.py

Attach a file by drag & drop or click to upload


Cancel
A new branch will be created in your fork and a new merge request will be started.