How Backstage Thinks

Last updated 7 August 2026

Backstage keeps four things apart: where content appears, what the content is, how it leaves the server, and what decides when any of it happens. The separation is deliberate. It is what lets the same application drive a single LED wall, a full dome, and a multi-server installation — and what lets you change one of the four without touching the others.

1. The scene — describing the room

The Scene View is a 3D description of the installation. Surfaces — flat screens, curved screens, domes, LED walls — stand at their real positions, with projectors or displays aimed at them. From that geometry Backstage works out how a flat video file lands on a curved, angled or irregular surface.

Nothing in the scene knows what is playing or which cable is plugged in where. It describes the shape of the world, and nothing else.

2. Content — assets and sequences

Assets are the media: video, audio, images, live capture. A sequence is a timeline that plays assets onto surfaces, and it targets a surface by name and mapping — never a physical port. The same sequence plays on entirely different hardware by changing the routing, with no edit to the sequence itself.

3. Outputs — virtual meeting physical

Outputs are where surfaces meet hardware: a GPU port, an NDI stream, a recording, an Art-Net universe. This is the only place Backstage knows about specific connectors, resolutions and refresh rates.

So replacing a projector, adding a GPU output or moving a display port is a change in Outputs alone. The scene and the content do not move.

4. Show logic — what decides when

Playback rarely just runs from beginning to end. Something has to decide when a piece starts, what follows it, what happens on a Monday morning, and what an operator is allowed to press. In Backstage that is its own part of the application, built in and first-class:

  • Sequencers run a timeline.

  • Steppers run a show as ordered steps, advancing on a cue, a timer, or the end of a loop.

  • Broadcast Schedulers run a timetable — a repeating week, plus overrides for a given date.

These exist in their own right. They are configured in their own windows, addressed directly by a control system over the show-control protocol, and put in front of an operator through a Web Console page. None of that involves the node editor.

This used to require the node editor, and no longer does. A stepper or a scheduler was once programmed inside a node, and there was no other place to do it — which is why people who learned Backstage then still look for it in the graph, and why they asked why it could not simply be set in the application. It can now. Each is an object of the project in its own right, with its own window, saved with the project whether or not any graph mentions it.

One leftover from that history: a stepper or scheduler that a node created is still owned by that node, and is removed by deleting the node rather than from its own window.

The node editor — extending it, and reaching outside

The node editor is not where the logic lives. It is how you extend that logic, and how Backstage talks to equipment that has its own ideas.

Reach for it when the built-in logic does not cover the case:

  • A device or protocol to integrate — a controller sending UDP or TCP, OSC from a desk, a serial device, a lighting console exchanging channel values.

  • A condition to evaluate — something that should happen only when, or only after, or only if.

  • A control surface shaped to one installation — the exact set of controls this venue's staff should see, and nothing else.

A graph can drive the built-in logic — start a stepper, jump a sequence, arm a scheduler — and it can react to what they report. It sits alongside them, not underneath.

How it fits together during a show

  • At load, the scene geometry is solved once: Backstage knows the shape and position of every surface and projector.

  • Show logic decides what should be playing — a stepper on its current step, a scheduler on its timetable, a sequencer on its timeline.

  • Content renders onto surfaces according to that decision.

  • Outputs carry the rendered surfaces to hardware.

  • Node graphs, where present, listen to the outside world and push commands back into the show logic.

Which part to check when something is wrong

Knowing which of the four is at fault is most of the diagnosis.

Symptom

Where to look

A surface shows nothing

Content — does the sequence target that surface and mapping?

The screen is black, but the scene looks right

Outputs — is the surface routed to a port at all? This is the most common cause of all.

Content plays, but the wrong thing at the wrong time

Show logic — which step is the stepper on, which entry is the scheduler in?

An external trigger does nothing

The node editor, or the show-control protocol — whichever route the trigger takes.

Geometry is wrong on a curved surface

Scene — the surface's shape and the projector's placement.

Nothing runs at all, or the server is unreachable

Not a Backstage question — the server itself.

Next steps

Your First Project — put the four parts to work in order

How Backstage keeps time — what all of it is timed against

How Backstage drives lighting — when the lights are part of the show