Signage Box vs Scenario Player
Exhibition teams have two different jobs for a screen. Digital signage loops a playlist. A scenario player waits for the room, the cue, or the show you already designed.
Signage vs a scenario
A signage box is a self-contained device that an operator manages through a visual interface. Think BrightSign, Samsung MagicINFO, or a Raspberry Pi running scheduled-signage software. The operator imports media, arranges a playlist or schedule, and the box loops it. The workflow is: import content, configure, walk away.
A scenario player is the display machine in a designed situation: a gallery room, an interactive booth, a show cue. It does not own the playlist. The system that owns the scenario — QLab, TouchDesigner, Companion, a custom app — sends load, play, pause, and reads status. The workflow is: install the player, point your controller at it, keep the logic in the scenario.
| Signage box | Scenario player | |
|---|---|---|
| Unit of work | Playlist and schedule | The scenario on the floor |
| Primary user | On-site operator updating content | Integrator, show programmer, control system |
| Control surface | Pad, web CMS, on-device buttons | HTTP/OSC from the system that owns the scenario |
| Playback logic | Built into the box | Lives in your application |
| Content management | Built-in (upload, organize, preview) | Not included — your system handles it |
| Deployment model | Standalone, self-sufficient | The player behind the screen |
| Typical scale | One screen, one box | Many rooms, one controller |
When signage is the right choice
If the requirement is a single screen looping a video in a lobby, and the person managing it is front-desk staff who will update content from a USB drive or a web dashboard — use signage. It is self-contained, it does not need a developer, and the operator can handle everything through a visual interface.
Signage is also a good fit when the schedule is the product: play video A in the morning, video B in the afternoon, rotate a playlist on weekdays.
When a scenario player is the right choice
The moment playback becomes part of a scenario — triggered by something in the room, in real time — the signage model breaks down. Examples:
- A museum exhibit that plays a specific video when a visitor approaches a sensor
- An interactive installation where a TouchDesigner patch decides what to play based on camera input
- A show-control rack where QLab fires video cues synchronized with lighting and audio
- A multi-room setup where 12 displays need to be orchestrated from a central controller
- A kiosk where a custom UI lets visitors select content, and the playback machine is hidden behind the wall
In all of these cases, the playback decision is not a schedule. It is a command issued by the scenario at an unpredictable moment. The player needs to receive that command and execute it immediately, then report state so the controlling system can verify what happened.
The player does not decide what to play. It does not manage content. It waits for the scenario and executes it reliably.
The architecture difference
With signage, intelligence lives on the device. The box knows the playlist, the schedule, the fallback behavior. The operator interacts with the box directly.
With a scenario player, intelligence lives in your application. The player is deliberately “dumb” — it plays what it is told, when it is told. Your show controller, interactive app, or automation script holds the logic.
Signage model:
Operator → Box UI → Box loops a playlist
Scenario player model:
The system that owns the scenario → HTTP/OSC → Player plays video
→ Player reports status backThis separation means you can change the scenario without touching the display machines, deploy identical players to dozens of screens, and integrate playback into systems that have nothing to do with a CMS.
Where DearScenario Player fits
DearScenario Player is a free scenario player. It runs on a Windows PC or Raspberry Pi behind the display, exposes one command model over HTTP and OSC, and reports state back to whatever system is cueing it.
It does not include a CMS, a scheduling engine, or a playlist editor. Those belong in the layer that owns the scenario, not in the player.
If you need a reliable, free, network-controllable video player for the scenario on the floor — that is what DearScenario Player is for.
Next step: Build an HTTP-controlled playback node to see the API in action, or download DearScenario Player and start integrating.