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
  • bridge
  • rig.py
Find file
BlameHistoryPermalink
  • PLN (Algolia)'s avatar
    lcxl: the panel could not see the daemon that lights the board · 72937cc7
    PLN, the night before a gig: "i dont see midi feedback visuel anymore on the
    LCXL fix this first plz". The hardware was fine. The daemon was gone.
    
    The journal had the whole story and nobody was reading it:
    
        lcxl-leds --watch: no LCXL sequencer port; retrying in 30s   (x8)
        Stopping LCXL LED watcher...
        Stopped LCXL LED watcher.
    
    The board was unplugged, the watcher retried, then it was STOPPED — and
    `Restart=always` does not resurrect a unit somebody stopped. On replug the
    board came back and the daemon did not. Three independent holes let that
    become a silent, session-long dark surface:
    
    1. `lcxl-leds-watch` was MISSING from rig.py's SERVICES table, so the Bridge
       panel showed a fully green rig over a dark board. That is precisely the
       failure the module's own docstring opens with ("A GREEN UNIT IS NOT SOUND"),
       one table row away. It was also in neither gig-up.sh nor converge: NOTHING
       on this box checked whether the surface was lit.
    2. The unit was `linked`, not `enabled` — it never started at login. It only
       ever ran because something started it by hand.
    3. `midi-autoconnect` was `disabled` too. The wiring it enforces
       (LCXL 20:0 -> Midi Through 14:0 -> SuperCollider in2) happened to be intact,
       so knobs still worked and the fault stayed invisible. But the prescribed fix
       for the LED stall IS a replug, and a replug drops those connections with
       nothing to re-apply them. The two failures compound: the remedy for one
       silently triggers the other, mid-set.
    
    Fixed: both units enabled, and the watcher is on the panel with a state that
    `active` cannot express. It retries forever by design, so "alive" is not "lit" —
    _leds_state() cross-checks the board via procfs and reports the third case
    honestly. No board is ABSENT, not broken; board present with the daemon down is
    "plugged in but DARK, start this", the one combination that was silently wrong.
    All five services now read green for a reason each, not by omission.
    
    Also, the daylight ramp. PLN: "maybe brightness can be leveraged, top
    brightness always would make more readable signals even in day perfs." The
    six-step unipolar ramp spent THREE steps on dim shades — exactly the budget
    that vanishes outdoors. The replacement keeps five steps and puts every one at
    full brightness by using the two mixed hues the old ramp never touched:
    
        red 15 (g0,r3) -> orange 31 (g1,r3) -> amber 63 (g3,r3)
                       -> yellow 62 (g3,r2) -> green 60 (g3,r0)
    
    Every value has a component at maximum, so nothing depends on a brightness
    difference to be legible. It costs one step and gains three readable ones —
    the same trade he already made for the DJ filters in July ("i agree on clarity
    > resolution"), which have been all-full-brightness ever since. This just
    brings the unipolar knobs in line. LCXL_DIM_RAMP=1 restores the old ramp, so
    a dark-stage revert is one env var and a restart, not a code change.
    
    And the gear's MIDI monitor: "super noisy ... cant we do way more dense".
    "Control change" spent 14 characters saying "CC", and a single fader sweep
    prepended ~100 near-identical rows. Events now abbreviate (CC/ON/OFF/PB/...)
    and consecutive events from the same control coalesce into ONE row that
    updates in place with a x-count — a 100-event sweep is one line, one DOM
    write per event, no node churn. Row height 20px -> 15px on top of that.
    
    Verified: 79/79 bridge tests pass; /api/rig reports all five services up with
    per-service proof; ramp asserted to have max(g,r)==3 at every step.
    PLN (Algolia) authored Aug 21, 2026
    72937cc7
rig.py 10.7 KB
EditWeb IDE
×

Replace rig.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.