Show Control
When you advance a patch in Pit, the lighting console fires its next cue, QLab triggers a sound effect, ProPresenter advances a slide, and the haze hits on Art-Net. One canonical timeline, many outputs.
This is the v2.0+ vision. The v1.0 architecture is deliberately decided so it doesn’t paint us into a corner: out-of-process plugins, transport state machine, theatre-vocabulary data model, allocation-free engine. All of those carry over directly into a Show Control surface.
The premise
Theatre show control is fragmented:
- Sound — QLab, SCS, custom rigs
- Lighting — lighting consoles (ETC Eos, GrandMA, ChamSys) running their own cue lists
- Automation — vendor-specific automation systems (Stage Technologies, Niscon, Tait)
- Video — Watchout, Disguise, QLab again
- Backstage cueing — stage manager calls, paging, comm
- Cross-system sync — LTC, MTC, Word Clock, GenLock
Most shows have at least two systems with overlapping cue lists. The stage manager calls “Sound Cue 42 GO” — the sound op presses a button on QLab, the lighting op presses a button on Eos, and if anyone misses or fat-fingers, the show falls out of sync.
A unified Show Control layer says: one timeline, many outputs. Pit’s transport drives MSC out to the LX console, OSC out to QLab, MTC to the video system, LTC to the audio recorder, DMX out to atmospherics — all from a single cue list authored by the MD.
Protocols (pro-theatre standard)
| System | Protocols |
|---|---|
| Lighting | DMX-512, Art-Net / sACN (DMX over Ethernet), OSC for newer consoles |
| Sound cues + playback | MSC (MIDI Show Control, 1991), OSC (QLab), Dante (audio over Ethernet) |
| Video / projection | OSC (Hippotizer, Resolume, ProPresenter), NDI for content |
| Automation | Proprietary per vendor; some MSC support |
| Comms | ClearCom / Riedel — separate analog/digital intercom |
| Cross-system sync | LTC (audio timecode), MTC (MIDI timecode), Word Clock, GenLock |
These are all open standards (or open-enough) — Pit can speak them with reasonable Rust crates + careful protocol implementation.
Latency budget — cross-system show control
| System | Tolerable | Ideal | Achievable on Cat6 LAN |
|---|---|---|---|
| Lighting cue advance | <50 ms | <20 ms | <2 ms |
| Audio cue trigger | <20 ms | <10 ms | <2 ms |
| Video cue trigger | <100 ms | <50 ms | <5 ms |
| Sample-accurate audio sync | <1 ms | <0.5 ms | requires word clock |
| Cross-system show step | <33 ms (1 frame @ 30 fps) | <16 ms | <2 ms over wired |
Network is rarely the problem. A properly-configured show network (wired Cat6, managed switch with QoS, dedicated VLAN) hits sub-ms. Actual bottlenecks:
- WiFi — 5–30 ms with variance. Don’t use for cues. OK for non-critical status displays.
- Receiving devices — lighting consoles often add 10–30 ms internal cue processing; QLab adds 5–10 ms
- Cellular — 30–100 ms+, never
Effort breakdown
| Capability | Effort | Notes |
|---|---|---|
| OSC sender / receiver | ~3 days | well-specced UDP, mature Rust crates |
| MSC sender | ~3 days | well-specced MIDI subset |
| Art-Net / sACN sender (DMX) | ~1 week | open standards, libraries exist |
| LTC encoder + decoder | ~2 weeks | audio-based, careful sync |
| MTC | ~3 days | trivial |
| Network discovery (Bonjour / Avahi) | ~1 week | auto-find consoles on network |
| Show Control panel UI | ~3 weeks | per-cue-system mapping editor; the hard part |
| Show Control templates (QLab, Eos, MA3) | ongoing | per-system spec packs |
Total: ~8–12 weeks for credible v1 Show Control. Slots v2.0 as a major theme.
The cue-list editor (v2.0+)
A new Program-mode surface dedicated to the cue list:
- Cues are timeline anchors (extends the v0.12.0 cue-point model)
- Each cue can fire any combination of MSC / OSC / DMX / LTC offset / etc.
- Cues can be grouped (Sound 42 + LX 42 fire together)
- Cues can be conditional (“if backing track is at bar 17, fire”)
- Cue list is exportable to QLab format for round-trip with sound ops
The UX is the hard part. Lighting ops and sound ops are the target users, not just keyboardists — this surface must be usable by people who didn’t author the Pit show. Most of the v2.0+ scope is UX iteration, not protocol coding.
Integration with Stardust Stage
The post-1.0 Stardust Stage runtime is the Stage Manager’s tool. Cue calls happen there, but the fire of those calls can be:
- Manual — SM taps a button
- Auto-fired by the Pit timeline (if the show is timeline-locked)
- Conditional — SM arms; Pit fires on cue point
Having Pit and Stage on the same data model matters here. A cue list authored in Pit’s editor is also visible in Stage; updates from either side propagate. This is post-v1.0 because Stage doesn’t exist yet — but the data model for cues needs to be roughly right in v1.0’s basic cue system (v0.8.0) so we’re not painting into a corner.
Viability by production scale
| Tier | Viability | Notes |
|---|---|---|
| School / community / regional / small touring | ✅ Fully viable software-only | Stardust as show brain works end-to-end |
| Mid-size regional / off-Broadway | ✅ Viable | Supplement with hardware where pros prefer it (talkback panels, hardware GO buttons) |
| Broadway / large touring | ⚠️ Viable for keys-and-musician layer | Full show control would typically still want a dedicated stage manager rig (Cuelab or similar) for risk isolation. Stardust integrates into that rig rather than replacing it. |
Where custom hardware would help (but isn’t required)
- Hot-spare redundancy — Broadway wants two-of-everything with auto-failover. Software-possible (two laptops + MIDI A/B switcher) but a purpose-built failover box is cleaner. Listed in v2.0+ backlog as Hot-spare rig.
- Hardware show buttons — physical Go buttons feel right for stage management. Stream Deck (v0.15.0 extension API) addresses most cases.
- Genlock / sample-accurate sync — requires Word Clock or hardware sync source. Software can request but can’t guarantee sample-level without hardware reference.
What this is NOT
- A QLab clone. QLab is excellent for what it is. Show Control in Stardust is for productions that want one canonical timeline running both the pit and the cues — not a QLab replacement.
- A theatre ERP. Cue lists yes; production budgets no.
- DMX fixture libraries. If Pit needs DMX, it’s at the protocol level — fixture knowledge belongs in Stardust Lighting (also speculative).
Adjacent work that has to land first
- Plugin sandboxing (v0.7.0) — out-of-process is a load-bearing decision the cue engine inherits
- Transport state machine (v0.8.0) — the timeline cue model rests on top of this
- Click track editor (v0.12.0) — cue points and timeline anchors get their first authoring surface here
- Extension API (v0.15.0) — third-party protocol implementations (proprietary lighting console protocols) live as extensions
Related pages
- Cue system — the current v0.8.0-scoped cue surface
- Click track editor
- Ecosystem roadmap
- Extension API