Control Playback via UDP
Backstage can receive plain text commands over UDP and map them to sequence actions — play, stop, pause, step advance, and more. You build this yourself in the Node editor, which makes it the route to take when you need a command vocabulary of your own.
This is not the standard remote control interface. For a control system driving Backstage, use the Enable and Configure the Show-Control Protocol — one connection covering steppers, sequencers, broadcast schedulers, calibrators, audio mixers and node endpoints, with live status feedback and no graph to build. Come here when you need a custom command syntax, a transport the protocol does not offer, or behaviour that has to live in the graph.
Before you start
- Your external controller can send UDP packets to the Backstage server's IP address
- You know which port your controller will send to (e.g. 7000)
- You have the Node Editor open with a sequence already set up in the Sequencer
Steps
1. Add a UDPReceiver node
Right-click the canvas → Network → UDPReceiver.
-
Set the Port to match what your controller sends to (e.g.
7000). -
Set the NIC dropdown to localhost to listen on all interfaces, or select a specific NIC.
-
Check the connected checkbox to start listening — the checkbox turns green when the socket is bound.
2. Add a Route node
Right-click → String → Route.
Connect the Message output of the UDPReceiver to the Input of the Route node.
Enter the command strings your controller will send — one per line. For example: PLAY STOP PAUSE NEXT.
The Route node creates one output pin per entry. When an incoming message matches a route, that output fires.
3. Add a Sequence node
Right-click → Sequence → Sequence. Select the sequence you want to control.
Action strings are case-sensitive — Play works, play does not.
Valid action strings:
|
String |
Effect |
|---|---|
|
|
Start or resume playback |
|
|
Stop and return to start |
|
|
Pause at current position |
|
|
Jump back to start and play |
|
|
Fade in |
|
|
Fade in and play |
|
|
Fade out |
|
|
Fade out then stop |
|
|
Fade out then pause |
4. Connect the routes to the Sequence node
The Route node strips the matched prefix and outputs the remainder (empty when the full message matched). Add a Datatype:String node for each command and set its value to the matching action string. Connect the Route output as a trigger to fire that string into the Sequence's Action input.
UDPReceiver Message | String:Route (routes: PLAY STOP NEXT) / | \ PLAY STOP NEXT | | | "Play" "Stop" "Restart" | Sequence:Sequence -> Action input
5. Test the connection
With the graph running, send a test packet from your controller or a UDP test tool. The UDPReceiver node displays the last received message. If the sequence responds, the wiring is correct.
Controlling a Stepper this way: the StepperCommander patch
To drive a stepper rather than a sequence directly, use the ready-made StepperCommander patch instead of wiring routes by hand. Right-click the canvas, open the Sequence category and select StepperCommander, connect its three outputs to the three inputs of a Sequence:Stepper node, and enable the checkbox on its UDP receiver.
It then answers these strings:
|
Message |
Effect |
|---|---|
|
|
Forwards an action to the active sequences, or starts the Stepper. Valid actions: |
|
|
Moves to the next step using the defined transition. On a step set to Await finish, the move waits until the end of the loop |
|
|
Changes immediately to that step, using the transition defined after the currently active step |
|
|
Jumps forward, or backwards for a negative value. Ignores Await finish |
|
|
Forwards an action to every StepperCommander in the project. Valid actions: |
|
|
Makes the Stepper emit its layout as a Pack of the sequences it uses and their durations. A connected StepperFeedback node turns that into a parsable JSON string |
These strings are a convention of the StepperCommander patch, not a Backstage protocol. The patch is built from ordinary nodes, so you can rename the commands, change the syntax, or accept a different transport entirely — which is the whole point of using it. With more than one Stepper on the same port, give each an Identifier and address it as /bs/stepper/[ID]/[Command].
Common Mistakes
-
Command received but sequence does nothing — the action string is case-sensitive. Verify the string in the Datatype:String node matches the exact casing in the action table above.
-
UDPReceiver connected checkbox stays red — the port is already in use by another process or a duplicate UDPReceiver node. Use a different port.
-
Route node fires but the Sequence Action input receives an empty string — the Route node outputs the remainder after matching (empty when the full message matched). A Datatype:String node with the correct action value must supply the string — the Route output is a trigger only.
-
You are reimplementing the protocol — if the vocabulary you are building is just play/pause/stop/next/goto, the JSON protocol already does it, with status feedback and without a graph. Use this route for what it is good at: syntax and behaviour that is yours.
Tips
-
The Sender output on the UDPReceiver emits the sender's IP and port — useful for logging or for sending a reply via a UDPSender node.
-
You can have multiple UDPReceiver nodes listening on different ports — one for sequence control, another for lighting cues.
-
To control a Stepper node from UDP instead of a Sequence directly, replace the Sequence node with a Sequence:Stepper and use its Bang input or step index input — or use the StepperCommander patch above.
Related
Remote Control — every route for driving Backstage from outside, and which to pick
Enable and Configure the Show-Control Protocol — the standard interface, if a custom vocabulary is not actually needed
Your First Graph — basic graph setup for beginners
Orchestrate Multiple Sequences with Stepper — multi-step show with a stepper
Playback — all show control and automation workflows