skip to content
Jason Worden
Table of Contents

Most software gets to fail in private. A lighting rig fails in public.

So this stopped being “an iPad app” pretty quickly. Supervision is now a finished live-performance system: a Raspberry Pi running the show engine, an iPad as the primary control surface, an intentionally limited iPhone companion for narrower remote control, an offline network pushing Art-Net into a LumenRadio Aurora and out over CRMX, plus optional-but-supported laser control through Radiator over TCP.

That product shape matters. The Pi is authoritative. The iPad is the main surface. The iPhone is not a second full console pretending to be one. Radiator is integrated when it’s in the rig, invisible when it isn’t, and the last laser preset is persisted and pushed again after reconnect.

Tube lights and laser filling the Parameter room with reflective panels

Live photo — the full Parameter room with tube lights, laser, and reflective panels, 5/14/2026. Photo by Mariah Tiffany.

The original question was simple enough: what would it take to make busking-style lighting feel playable for DJ and electronic sets? No timeline programming. No cue stacks to babysit. Just scenes, overlays, bursts, tempo control, and a system I would trust live.

Two rules drove almost every decision:

  1. The show should keep running if a controller disappears.
  2. The operator needs immediate control, not a preprogrammed timeline.

Those rules are why the engine lives on a Pi instead of the iPad, why the LAN is intentionally offline, why the engine loop is isolated in a worker thread, why scene state is checkpointed to SQLite, and why every controller stays a client of the same source of truth.

This series is the recruiter-skimmable version of that build: what the system is, why it is shaped this way, and which engineering decisions made it reliable enough to use for an actual set.

Performer during the set with the laser path carrying the room

Actress for Parameter, 5/14/2026. Photo by Mariah Tiffany.

Node.js · TypeScript · worker_threads · WebSockets · SQLite · Art-Net · CRMX · offline-first network design

The series

  1. Not an iPad App: Why the Show Engine Lives on a Pi
    The whole rig in one pass: Pi as authoritative engine, iPad as the main controller, iPhone as a scoped companion, and why the “just put it on the tablet” version was the wrong system.
  2. Offline on Purpose: Designing the Show Network and Telemetry to Survive Failure
    The network topology that keeps the show local: offline router, Pi on Ethernet, Aurora on Art-Net, CRMX to fixtures, and clean failure boundaries when the venue Wi-Fi is a mess.
  3. Building a 44 Hz Engine That Doesn’t Flinch
    Worker-thread isolation, fixed-tick output, and the deliberately boring hot path that keeps scene changes, effects, and output timing predictable.
  4. Never Go Dark: Designing Crash Recovery for a Live Show
    SQLite checkpoints, command ordering, and the exact state that gets restored so the system comes back in a usable place instead of starting cold.
  5. One Protocol, Two Different Clients
    How shared state, reconnect behavior, Radiator integration, and persisted lastLaserPreset make the iPad, iPhone, and optional laser path behave like one system instead of three separate apps.

If you want the short version: I didn’t mean to build a distributed system. I meant to build performance gear I could trust live. The distributed system was the part I had to build to make that statement true.