A picture is not a show. A show is the picture plus everything that comes and goes on top of it: a name under the guest, a score in the corner, a breaking news strip, a stinger between segments.
How those things should work turned out to be one of the most important decisions in the project.
The usual answer, and its problem
The common answer is to make an overlay just another layer inside a scene. It is simple, and it falls apart quickly in a live show.
Say a guest’s lower third is on air and you cut to a wider camera. If the lower third lives in the first scene, it disappears with it. So you copy it into the second scene, and the third, and keep them in sync by hand. Change the guest’s title once and you are editing it in five places, live.
The overlay was never part of the scene. It belongs to the show.
Overlays as channels
So in Muxivo Studio, overlays live on their own channels, above whatever scene is on air.
A channel has its own position, size and stacking order, and its own timing. You can switch scenes as often as you like and the lower third stays where it is. You can take it off on its own schedule, with its own transition, without touching the scene underneath.
Several channels run side by side: one for lower thirds, one for a score bug, one for a ticker. Each is independent, so one never knocks another off air.
This small change in structure removes a whole class of live mistakes. It also opened the door to something bigger later: channels that play from their own queue of content, which became a central part of the workflow and deserves its own story.
Transitions and stingers
With scenes and overlays in place, the next step was how things change.
Transitions came first: cuts and timed transitions between scenes, with custom durations. Preview and Program were matched in colour, so what you prepare is what goes on air. Videos waiting in Preview pause until they are taken live, instead of running ahead unseen.
Overlays got their own transitions too, independent of the scene transitions. A lower third can slide in while the scene underneath cuts.
Stingers followed: a short animated clip that plays over the change and hides the cut underneath. They are easy to describe and surprisingly hard to get right. The cut has to land at the exact moment the stinger covers the screen, every time, regardless of what else the render loop is doing. It took a rework of the rendering pipeline to make them dependable, and it was worth it.
Scripting, earlier than expected
Somewhere in the middle of all this I stopped and added scripting.
That was earlier than the plan, and on purpose. Every feature built without automation in mind has to be retrofitted later, and retrofits are where tools get their awkward corners. If scripting exists from the beginning, every new feature is built with it in mind.
Muxivo Studio uses Lua: small, fast, easy to learn, and widely used for exactly this kind of embedding. From the first version, scripts could drive scenes, overlays and text.
The longer-term principle is stricter: anything the interface can do, a script can do, through the same operations. That principle shaped much of the later architecture, and it is also what makes room for AI agents to operate a show one day.
Where things stood
By now the pieces of a real show existed: scenes, effects, a first sense of space, overlays on their own channels, transitions, stingers and scripting.
But all of it still lived inside one application window. A show has to get out of the machine, to screens, to other software, to the audience. That is the next chapter.