Resource
Media - video, audio, images - plus text, an LTC generator and a live audio input. Resources live in the library and are reused across cues instead of being reconfigured in each one.
Four kinds today; the model is built to take more.
Video, audio, images and text on a native C++ engine - plus OSC, MIDI, LTC/MTC timecode and NDI/Spout output to drive the rest of the rig. The editor is a separate process: closing it does not stop the show.
Media - video, audio, images - plus text, an LTC generator and a live audio input. Resources live in the library and are reused across cues instead of being reconfigured in each one.
Four kinds today; the model is built to take more.
Three kinds. Command plays, pauses or stops. Set jumps a parameter to a value. Transition moves it over time on a curve. The engine clamps every value to the parameter registry.
command · set · transition
Nine, and only nine - a closed set, so an action’s timing is always one of a handful of things you can read off the cue.
On Cue Start · On Play · On Cue Stop · On Finished · At Time · Timecode · OSC · MIDI CC · Manual
A media cue plays because the cue lifecycle plays it, not because you added a Play action. Actions are what you build around that lifecycle.
A show-control system earns trust by being specific about what it is doing - and about what has stopped working.
Cue list, transport and live system state, as the current beta draws them. Click a cue to arm it, or press GO.
Three of the nine triggers are reactive - OSC, MIDI CC and Manual. They arm when the cue starts playing and can fire repeatedly until it stops.
Press ◎ Learn on an action, move the controller, and it binds that channel and CC. GO and PANIC learn the same way; over OSC they are /go and /panic.
If chased timecode drops out, the internal generator freewheels from the last frame, so timecode-armed cues keep firing through the gap.
Playback, timing and show state live in a separate native C++ process. The editor is a protocol client that draws the interface, and a headless runtime runs shows with no interface at all.
The project defines one canvas - width, height and frame rate. The program is composited once at that resolution and every output adapts it.
A render coordinator owns the D3D11 device, context and swapchains, composites once and blits to each output, rather than a thread per output contending for the GPU.
Decoding runs on a dedicated NVDEC device, so several clips do not serialise against Present. A clip that decodes badly there is caught when it opens and falls back to CPU on its own.
Frames are decoded at the size the canvas actually needs - measured at roughly 4× on 4K down to 1080p.
Documents are op-based, journalled and saved atomically, so a crash leaves the show recoverable. The engine runs under a watchdog that restarts it after an abnormal exit and gives up on a crash loop rather than thrashing. A fault writes a minidump, a log and a report bundle to the operator’s own disk - offline, no server involved.
A six-hour operator soak at 3440×1440 with NDI and Spout running, on GPU decode: no leaks, no handle growth, zero underruns, and a monitor topology change recovered without a restart.
A real GPU device loss. A monitor power-cycle is a topology change, not a device loss, so that path remains untested.
The manual keeps the full list, feature by feature, with what each one does and does not do: Capabilities and limitations ↗
For operators who today run QLab, Resolume or a media server - in theatres, on tour, in installations and in corporate AV.
Test a real Windows build, complete a 60–90 minute test mission and speak directly with the developer.
The key arrives by email and activates two computers. Questions rather than a license? [email protected].