Picture and audio are the classic signals of a show. Today there is a third one that most tools still treat as an afterthought: data. Chat messages, poll results, scores, donations, questions from the audience, the time in another city.
This chapter is about how that data reaches the screen, and about the decision behind the graphics that show it.
Why HTML
Broadcast graphics have traditionally meant a dedicated graphics system, or a template editor with its own rules, its own animation model and its own limits.
Muxivo Studio graphics are plain HTML. A lower third, a ticker or a poll is a small web page with a transparent background, composed into the show like any other source.
That choice is deliberate:
- Anything you can design, you can put on air. CSS animation, SVG, canvas, WebGL, any font, any layout. There is no graphics language to learn.
- AI is a real design tool here. Describe the lower third you want and an AI assistant can write it. You can iterate on a look in minutes instead of hiring a template designer.
- The skills already exist. Countless people can build web pages. Very few know a proprietary graphics package.
HTML is the easy part, though. The hard part is everything around the graphic.
The platform behind the graphic
A graphic on its own is a static page. On a live show it needs data, controls, timing and a way to be shown and hidden reliably.
That is what Muxivo Studio provides, the same way for every graphic:
- Live data from connections such as REST endpoints, WebSockets and streaming platforms, delivered to the widget in a predictable shape.
- Field mapping, so the data’s fields are matched to what the widget expects, with fallbacks and manual overrides when a feed misbehaves.
- Live controls defined by the widget itself, so an operator gets the buttons and fields that make sense for that graphic, not a generic form.
- Independent instances. Use the same ticker twice with different data and settings; each one keeps its own state.
A growing library of ready-made widgets uses exactly the same platform: tickers, polls, chat and question walls, live alerts, clocks and animated titles. They are examples of what anyone can build, not privileged built-ins.
A home for live controls
Graphics with live data create a lot of controls: approve a question, pin a chat message, start a poll, reset a counter.
Those controls live in a dedicated Live Controls workspace, organised in groups on a grid. It can move to its own window on a second monitor while the main live workspace stays where it is. One operator runs the show; another runs the graphics, side by side.
Queues: the show as a running order
Back in the overlays chapter I promised more about queues.
A queue is a running order of content: images, videos, audio, scenes, web graphics and presentation pages, each with its own duration, transition and behaviour. Queues are saved with the project, reusable and organised in folders.
You load a queue into an overlay channel or onto a layer in a scene and play it: a sponsor loop in the corner, a slideshow full screen, a playlist of clips between segments. Preview shows what is next without touching Program, and taking the next item is a single, predictable action.
Picture, audio, data
Here is where this is heading.
Today, data flows through connections, mapping and processing steps that are configured in forms. That works, but it hides the shape of the flow. The next step is to make data a first-class signal with its own visual flow, like a node graph:
- Take data from any source.
- Shape it inside the application: filter, transform, combine, without external converters or glue scripts. If no built-in step fits, write your own.
- Map the result to the exact schema your widget expects.
- See the whole path at once, from where the data arrives to where it ends up on screen.
Then a show has three equal flows: picture, audio and data, each with a proper graph of its own. The data flow is the newest of the three and still on the drawing board, but it follows the same idea that shaped the audio graph: model the real flow, instead of adding features around it.
Next
Live data means talking to many outside services, and every service is different. Building each integration into the application would never scale, and letting third-party code run freely inside a live show would be reckless.
How to open the platform to anyone’s plugins without taking that risk is the next chapter.