Live production software, reimagined

BackStageOS

One local-first, peer-to-peer operating system for the whole production.
Every department, every stage of a show’s life, on one shared production graph.

The vision
The lighting app
Roadmap

The problem

Live production — theatre, events, broadcast — is run on a patchwork of disconnected, proprietary tools.
Every department bought its own island, and nothing shares a single source of truth.

The department silos

  • Lighting design and visualisation — WYSIWYG, Capture, grandMA and Eos ecosystems
  • Audio — Fairlight, proprietary DAWs and live consoles
  • Video and live switching — vision mixers, media servers, vMix and OBS
  • Cue playback — QLab and friends
  • Management — spreadsheets, WhatsApp, paper call sheets, binder prompt books
  • Comms — closed hardware intercom systems

What that costs

  • Data is siloed per department. Lighting does not know the set; sound does not know the video cues.
  • Costs lock out small companies. A single WYSIWYG subscription is out of reach for many small and independent productions.
  • Nothing talks to anything without brittle glue and manual re-entry.
  • The paperwork and the show are different worlds, so information never flows from pre-production into the performance and back.

The vision

BackStageOS is one local-first, peer-to-peer operating system for the whole production,
covering every department and every stage of a show’s life.

  • All departments — lighting, sound, video, stage management, cast and crew — work against one shared production graph.
  • The system spans pre-production to design, rehearsal and tech, live performance, broadcast and debrief.
  • It runs on one laptop for a one-person show, or across a mesh of dedicated appliances for a full venue. Same system, different deployment profile.
  • Live production can be broadcast out to streaming platforms or TV as part of the same stack.
  • It scales up to venue management — the system a building runs on.

The Product Family

BackStageOS

The production OS: the whole platform for a show, from pre-production to broadcast.

VenueOS

The venue OS: the software a building runs on — digital signage, box office, EPOS and building systems.

Maestro

A line of hardware consoles for Lighting, Sound Video and Stage Management as well various nodes to the capture and distribution of input and outputs for the mesh.

All three share one core: the graph, the runtime, the mesh and identity.

Guiding principles

  • Local-first, peer-to-peer, no single point of failure.
  • One shared production graph as the point of contact for everything.
  • Two planes: authored truth (the graph) versus deterministic execution (the runtime).
  • Bridge first, own later — integrate existing open tools before rebuilding them.
  • Open everything — protocols, formats and data; import from proprietary tools wherever possible.
  • Scales from 1 to N — laptop, console or venue mesh, from the same code.
  • Individually adoptable, collectively integrated — each app stands alone and clicks into the stack.
  • Failover is designed in from day one, not bolted on.

Architecture: two planes

The discipline that keeps a system this ambitious finishable is a small number of hard boundaries
— chief among them a separation between what the show should be and what the show does.

Authoring plane — the graph

  • Local-first, CRDT-backed, multi-user and asynchronous.
  • Holds every authored fact: script, cue stacks, patch, fixture profiles, schedules, people, notes, assets, design data.
  • Every department edits here. Every surface reads here.
  • Works offline; syncs and merges when peers meet.

Execution plane — the runtime

  • When a show is armed, the relevant slice of the graph is compiled into a deterministic show file.
  • Runs the cue engine and timeline with no CRDT in the hot path — jitter would destroy timing.
  • Holds the Show Position: one shared cursor of timecode, script position and cue state.
  • Writes the log back into the graph — what actually happened, timecoded.

Everything reads from the graph — either live while editing, or as a compiled snapshot while running. That is the difference between a document and a machine.

Surfaces      desktop · department consoles · Maestro · mobile
Execution     runtime · cue engine · timeline · Show Position · override layer · log
Authoring     production graph (CRDT) · core + pluggable domain namespaces
Placement     node manifests · intent to capability binding
I/O engines   DMX/sACN/Art-Net · audio (AES67/Dante) · video (SDI/NDI) · OSC/MIDI/GPIO · time
Mesh          P2P transport · content-addressed storage fabric

Deployment profiles

same code, different scale

ProfileShape
SoloOne machine runs every engine; outputs via local interfaces and dongles.
ConsoleOne appliance runs the show with a purpose-built surface.
Venue (hub + nodes)A hub coordinates; edge nodes provide dedicated outputs.
Multi-siteFederated across venues and touring.

Why it is different

The market does not lack tools — it lacks the integration.
One graph, one runtime, everything designed to work together is the moat, not any single feature.

One shared graph

Lighting, audio, video, stage management and venue are designed to click together. Every department works against the same authored truth.

Local-first,
failover by design

No single point of failure. Network-native output — sACN, AES67, NDI — means any node can drive the pipe, not just the brain.

Adoptable,
then integrated

Use one app on its own; add the rest as progressive enhancement. Nobody has to buy a whole OS to get one tool.

Open everything

Open protocols and formats, and import from proprietary tools wherever possible. Bridge existing open engines before rebuilding them.

Version control
and reuse

Git-like history over the graph, with libraries so cues, palettes, sounds and templates are reused across shows by reference — not copied.

Cue-aware comms

A software intercom matrix where the stage manager’s calls are timecoded against Show Position. The comms are the documentation.

Standards, not silos

BackStageOS speaks open protocols and interchange formats, and never parses proprietary files directly
It uses the source tool’s own exporter or a headless conversion.

DomainOpen standard
Clock / timebaseIEEE 1588 PTP
AudioAES67 / ST 2110-30 (Dante via bridge)
VideoSRT / RIST / NDI / ST 2110; WHIP and WHEP for web monitoring
LightingsACN (ANSI E1.31) / Art-Net
Stage and rig geometryMVR / GDTF
ControlOSC / MIDI
3D interchangeUSD / glTF / Alembic
Video and editOpenTimelineIO / EDL / AAF

Roadmap: four horizons

The roadmap is directional, sequenced by user value and dependency rather than technology fashion.
Each horizon should leave something usable, not just scaffolding. The current phase is ideation.

HorizonFocus
1 — The OS coreProve the spine end-to-end: production graph, the compile and arm contract, the runtime and Show Position, placement, identity, failover, timebase, one surface and one output engine (sACN).
2 — The department appsLighting, audio, video, venue design and stage management — individually adoptable, collectively integrated. Bridge-first integration with existing open engines, plus the built-in virtual rig and rendering.
3 — The platformVenueOS breadth (digital signage, box office, EPOS, building systems), broadcast-out, cross-site federation, and the Maestro console family.
4 — Adjacent markets (gated)Rendered and virtual shows, virtual sets, games and virtual concerts, newsroom — only once the beachhead and the platform are solid.

Milestone 0 — the pulse. A single program: one production, one fixture, one cue, one sACN packet, one GO button. Prove the pulse, then grow the body.

The beachhead: an open lighting app

The first product wedge is a lighting design app — an open, local-first replacement for WYSIWYG (Cast) and, by extension, Capture.
Paperwork is universally needed, and the open standards make it tractable: GDTF for fixture personalities, MVR for the rig, sACN / Art-Net for DMX, DXF/DWG for drawings, and IES/LDT for photometry.

The production graph is truth; the CAD document is a projection; the visualiser is a reader.

PhaseGoal
Phase 0 — Spike (done)Proved reading real venue drawings, parsing GDTF and MVR, emitting sACN and Art-Net, and rendering a beam on wgpu at roughly 590 fps. Settled CADCraft integration: own the app, depend on the foundation, never fork.
Phase 1 — Plot and paperworkVenue to graph, the plot, editable schedules and PDF paperwork. The honest wedge.
Phase 2 — Patch and universesDMX patch, Art-Net and sACN out and in, visualise levels, connect a real console.
Phase 3 — The visualiser3D venue and set, fixtures with pan, tilt, colour, gobo and beam; haze and camera. Driven by live DMX or the internal runtime.
Phase 4 — Show and console integrationPalettes, groups, effects and cue stack on the graph; the visualiser follows Show Position.
Phase 5 — Reports depth and riggingData sheets, magic sheets, focus charts and followspot sheets; advisory rigging and load.
Phase 6 — Collaboration and cross-departmentCRDT multi-user editing, share and collaborate, and cue-aware comms.

A firm boundary: we advise, certified hardware executes

Anything that can hurt someone — motion, loads, crowd, fire — stays in certified hardware. BackStageOS advises, coordinates, visualises and logs, and is never the certified executor.

  • For regulated systems we are read-mostly and advisory: surface status, raise incidents, run H&S checklists.
  • Building systems (BACnet, Modbus, KNX) are integrated, not replaced. We must not become the fire panel.
  • Keep-clear areas and capacity zones are represented, checked and warned about — never certified.
  • The pitch stays honest: one pane of glass for a venue manager, without owning life safety.

Status

Current phase: ideation. The vision, architecture, data model, identity, runtime, interop, venue model and roadmap are written. The lighting app’s Phase 0 spikes are complete — real venue drawings read losslessly, GDTF and MVR parsed, sACN and Art-Net emitted, and a volumetric beam rendered on wgpu. No production code has shipped yet.

Work is tracked in the project docs: vision (00), architecture (01), data model (02), identity (03), runtime and failover (04), engines and interop (05), venue management (06), roadmap (07), and the lighting app plan (18).