CNDL
A specification for computing dynamic arrays of values.
CNDL describes a scene as arithmetic on a buffer of shape (fixture count × channel count), recomputed per frame from fixture coordinates, elapsed time, and external input signals. Designed around lighting, but any output addressable as a per-element numeric value — moving heads, single-channel dimmers, DMX-controlled motors — fits the same model. The file is plain text. Any compliant runtime executes it unchanged. The spec is working but still evolving.
A buffer, shaped by inputs across time and space.
The scene state is a 2D buffer: one row per fixture, one column per output channel. Each fixture carries an (X, Y, Z) position in physical space. Every frame, the runtime computes the buffer from those positions, elapsed time, and a small set of external input signals. Operations are vectorized: a single op runs across all fixtures at once. A wave does not pulse uniformly across the array — it travels, because each fixture enters the wave at a phase determined by where it physically sits.
The Pipeline
Data flows in one direction through the pipeline. At every stage, the question is the same: what happens to the buffer?
Coordinates, signals, time.
Fixture positions (XAX, YAX, ZAX) loaded once from a survey or CAD export. Elapsed seconds since scene start (TME). Up to four external control signals (RX1–RX4) driven by sensors, sliders, console channels, or upstream commands. Two random sources: RNG (one value per frame) and SNO (one value per fixture).
Vectorized arithmetic, per frame.
A topologically sorted graph of named nodes. Each node runs a single opcode — ADD, MUL, MAD, LRP, WAV, STP — against its parameters, producing one value per fixture. Nodes reference other nodes by name. Outputs of one node feed inputs of the next.
Four channel slots.
Up to four TX channels (TX1–TX4) per scene. Each TX binds a computed node to an output column. The runtime decides what those columns mean for the install: RGB, RGBW, intensity, dimmer, pan, tilt, zoom — any per-element numeric value it knows how to emit downstream.
The spec does not specify this.
A microcontroller driving WS2812 or DMX512 directly. A single-board computer streaming Art-Net or sACN. A desktop authoring tool previewing on screen. A GPU server at scale. The same file runs in all of them.
The Operation Set
Sixteen compute primitives, four input channels, four output channels, and DEL for incremental edits. Every scene is composed from this set.
Scope.
What CNDL describes, and what it deliberately leaves alone.
What the spec covers.
The buffer model. The operation set. Per-element computation against physical coordinates, time, and external inputs. Deterministic frame-by-frame output. Plain-text file format. The runtime contract: given the same file and the same inputs, every compliant runtime produces the same values.
What the spec does not touch.
Cue lists, timelines, and show control. Audio or video synchronization. GPU shaders and texture sampling. DMX patching and fixture personality libraries. Network discovery and device provisioning. Authentication, encryption, transport. These belong to the runtime or to the layer above it.
What the runtime decides.
How the file is loaded. How external inputs are wired in. Which output protocol carries the buffer downstream. How errors are reported. Whether the scene is hot-reloadable. The spec leaves all of this open. A microcontroller and a GPU server will answer these questions differently and still run the same file.
The authoring tool.
Three panels, cross-platform. On the left, the operations text — the file itself, one line per operation. In the middle, a node graph that mirrors the text: wire inputs to processing to outputs. On the right, a 3D point-cloud preview rendered against the actual geometry of the install. A serial terminal connects to a running device for live-coding during commissioning. The text, the graph, and the device stay in sync.
One file. Many runtimes.
The same .cndl file is portable across the full range of runtime targets. New runtimes built tomorrow will run today's files without modification.
Microcontroller, on site.
The file runs locally on a small device, reading sensors and driving pixel protocols (WS2812, SK6812, APA102, DMX512) directly. No PC, no network required. The shape of a distributed install that runs unattended. The Eos Pixel Driver is one implementation, built on MicroPython and the RP2040 PIO.
Art-Net · sACN · KiNET.
A headless application loads the file and streams computed values over the network. Runs on a single-board computer or a rack-mounted server. Accepts real-time control over OSC, UDP, or HTTP.
CNDL Maker.
Visual editor with live preview. Build scenes, adjust parameters, and watch results against the real point cloud before deploying. Cross-platform, no GPU required.
Server, at scale.
A server-side renderer executes the pipeline on a GPU when the element count exceeds what embedded hardware can carry. Same file, larger buffer.
…and a runtime that does not exist yet, built tomorrow for new hardware, will run today's files without modification.
A spec, not a product. A file.
CNDL is a file format and a runtime contract. It is narrow on purpose. For the class of work that does not fit a screen-shaped pipeline — point-cloud layouts, mixed-personality fixtures, moving heads driven alongside pixel tape, distributed deployments, systems that run unattended for long periods — CNDL describes a different shape.