Backstage

Backstage builds and runs the show. It is where the venue is modelled and the picture is fitted to its real surfaces, where content is arranged in time, and where the logic that drives it all is programmed. It is also what plays the result, day after day.

The server is the hardware under it, prepared first in Brainsalt Hub — addresses, displays, users, power. Anything about the machine is the Hub; anything that reaches a screen is Backstage.

Backstage separates three things: where content appears, what the content is, and what decides when it plays. That separation is the product’s model, and it is the order of everything below.

Scene — where content appears

A scene is the set of surfaces the show plays on: projection surfaces and displays, and the projectors that cover them. Surfaces can be flat, curved, dome, spherical, or an imported 3D model.

For projection, the projectors are placed as they stand in the venue. That placement is not decoration: warping and blending are calculated from each projector’s real position and orientation relative to the surface. Displays are addressed in pixels, so placing them to match the venue is optional.

The projection wizard builds a complete projection setup in one step, projectors already aimed, and its parameters stay editable as the design moves.

A display surface can be drawn as the LEDs themselves rather than as a continuous picture. The Scene View renders the individual pixels at the pitch and LED size of the product being specified, so content can be judged on the wall it will run on — whether type is still legible at that pitch, and how much of the image survives it — while the wall is still a drawing.

The same works for sparse installations, where the pixels are strips on a building or tubes through a space rather than a continuous panel: one dot per LED, mapped across the faces of the model or along its centreline.

Content — what plays

Everything Backstage plays is an asset: video and audio files, and live sources. Once an asset exists it behaves the same way whatever it came from, so a camera feed and a rendered clip are placed and played identically.

Files are imported directly, one at a time or as a batch. Where a format needs converting first, the Drop Converter on the server takes files in and returns them in a playback format.

Live sources become assets in the same way: NDI over the network, SDI or HDMI capture cards, another application’s window captured from a virtual monitor, and real-time renders from Unity.

Playback — what decides when it plays

A sequence has one or more channels — video, audio, or node datatype. On each channel you place one or more assets, optionally with transitions between them. A video channel renders to a surface through a mapping on it, audio channels feed audio devices, and node datatype channels carry strings, floats and colours into the node editor, so the timeline drives external devices as readily as it drives picture and sound.

Where a show needs one sequence, that sequence plays on its own. The stepper orchestrates several: a step runs one or more sequences in parallel, and moving from one step to the next runs them in a row, optionally with a transition. Steps advance by hand, by an external trigger, or when a sequence finishes — which is what makes a clean join possible: hold an entrance loop running, then advance at the end of the current loop so the move into the main content lands on a seam rather than a cut. A step can also jump straight to another step, fading a capture overlay in over a background that never stops and out again on the next step.

The broadcast scheduler runs a week plan, for venues with fixed daily or weekly programming.

Warp, blend and black level

This applies to projection. A display shows content directly and needs none of it.

Geometry first. Warp meshes can be built by hand from planar, cylindrical or toroidal base modes, or generated from a camera: CalibratorLite is built into Backstage at no extra licence and produces warp meshes and projector frustums from a single camera on a planar or cylindrical screen. The separate Calibrator product covers multiple cameras, any screen shape, and black level.

Where projectors overlap, both are lighting the same pixels. Blending ramps each one down across the overlap so the join disappears.

Black level is optional, and worth deciding rather than assuming. Continuously bright content never shows the black floor; dark content shows the overlaps as brighter patches on an otherwise black screen. It is measured with a camera, and there is no by-hand alternative worth attempting — DLP projectors emit light outside the addressable pixel area, which no amount of work on the content side can compensate for.

Output

Routing connects the scene to hardware: each projector and display to the GPU output it is cabled to. Until that is done a scene can be entirely correct while the screen stays black — which is also why a project can be built and its content played anywhere, and routed only once it reaches the installation.

Audio is routed the same way. An audio output is created for the device and channel count in use, and whatever should reach it is connected. A matrix mixer covers the cases where the channel counts going in and coming out differ, or individual channels need adjusting on the way.

Art-Net and sACN make a third kind of output: image pixels mapped to DMX channels, so LED fixtures and architectural lighting are driven from the same content as the screens.

An output whose display is unplugged or moved can be recovered with its routing, warp and blend intact, and an output can be switched off without being removed.

Show logic — the node editor

The node editor is Backstage’s visual programming surface. Where a show needs logic the built-in windows do not cover — a custom trigger, a conversion between protocols, a control of your own design — it is wired here.

It is not a stage in the build order but a tool used across them. A graph can start and drive a sequence, patch Art-Net, answer a UDP command, or put a switch on screen.

Templates cover the common jobs — network parsing, sequence control, audio routing, string handling — so a graph rarely starts from nothing.

A Presenter area exposes only the controls one show needs and hides the wiring behind them, inside Backstage’s own interface, locally or over a streamed session.

Remote control

A finished show is driven from outside Backstage by one of three routes, chosen by what is doing the driving.

The JSON show-control protocol is the standard interface: a control system drives the show over TCP or UDP, and everything reachable is reachable through it. Sequence transport, position, speed and fades. Stepper transport and step selection. Audio levels and mutes. Alignment and black-level passes. The week plan. NDI input routing. And any endpoint a graph of your own chooses to expose. It is off until enabled.

A Web Console is for a person rather than a system: a page built in Backstage and served to any browser, with no Backstage interface involved. A node-editor graph covers whatever the first two do not.

Alongside those: OSC, for show-control applications and lighting desks that speak it. Plain UDP triggers from a hardware controller. Control surfaces driven over the JSON protocol, with feedback and ready-made presets. And Art-Net or sACN channel values exchanged with a lighting desk in either direction — which is a different job from driving fixtures as pixels, and that one is an output.

The Automation API is a wider grant than show control. Over HTTP, and with an MCP endpoint for AI agents, it can build scenes and import media rather than only operate a show that already exists.

Monitoring

The Performance Overview is the pre-show check, and it reports per render group: frames per second, total frame time, GPU render time and vsync time, each with its current value, a moving average and the maximum, over a plot of vsync deviation. GPU memory is broken out by heap, by usage category and by pool. The same figures can be laid over the rendered output itself, so a show can be watched while it runs without leaving the scene view.

Each playing stream gets its own panel: scheduling deviation and delivery latency plotted over time, how full the playback buffer is, and a row of coloured squares showing the state of every frame in it. The counters underneath are the part worth knowing about. They separate frames skipped, repeated or jumped deliberately — catching up to sync is a normal thing for a media server to do — from skips caused by render lag, disk read errors, transfers that did not finish, and frames that were not there when they were needed. A single dropped-frame number cannot tell those apart, and the difference is the whole question of whether a show is working as designed or in trouble.

The log makes the same distinction in words. A warning is an expected operational state, almost always something this particular machine does not have: media the project references but this server has not mounted, an audio device the project names but the machine lacks. Nothing is broken, and a project built on another server produces a wall of them by design. An error is a program fault, and those are worth chasing. One fault is reported once rather than cascading, so several distinct errors mean several distinct problems.

Maintenance watches the media drives themselves: read and write performance, and the data ageing that affects solid-state drives over time. On a machine whose job is to read large files quickly and on schedule, that is worth knowing before a show finds out.

Whether an output’s link is up and has the bandwidth for the mode being asked of it, and how the machine itself is doing, are read on the server side in Brainsalt Hub. That side keeps reporting whether or not Backstage is running.

Specifications

Verified against the current build.

Scene and mapping

Media formats

Live and generated sources

Colour management

Output

Recording

Stereoscopic

Synchronisation and timecode

Pixel processing

Show logic and integration

Third-party hardware

Most of what Backstage plays needs no hardware beyond the server. These are the parts where the make and model matter, because Backstage drives them through a driver or SDK of its own.