vMix for live events: a producer’s guide to the vision mix

vMix is a software vision mixer for Windows. It takes camera feeds, presentation content, video files, remote guests and graphics as inputs, lets an operator cut and mix between them, and outputs the result to a stream, a recording, a projector or an LED wall. It replaces, for many events, what used to be a hardware switcher and several separate boxes around it.

The reason it appears so often in event production is scope: within one application you get switching, titles, playback, recording, streaming and a multiview, and the whole thing travels as a laptop or a small rack PC. The reason people get burned by it is the same one — it is a computer, and it is subject to everything a computer is subject to.

This is where vMix stops being a software decision. The application is only as reliable as the machine underneath it, and the specification is driven by how many inputs, at what resolution, and whether it is also encoding a stream at the same time — encoding and mixing compete for the same machine.

Video inputs arrive either over the network or through a capture card, and a card means a desktop-class machine with slots rather than a laptop. Storage matters if you are recording, and recording to the same disk you are playing back from is a well-known way to find out how fast that disk actually is.

The single most important preparation step is unglamorous: turn off automatic updates, sleep, screen savers and notifications on the machine before the show. A vision mixer that decides to restart for an update during a keynote is a story every producer has heard and some have lived.

Broadly two routes: down a cable into a capture card, or over the network. Cameras and presentation feeds typically arrive on SDI or HDMI into a card. Network video — NDI is the common example — arrives over ethernet, which is convenient and removes cable runs, and which makes the reliability of the venue network a production concern rather than an IT one.

Remote guests are a third category and behave differently again: they arrive over the public internet, with the latency and instability that implies, and they need their own return feed and talkback so they can hear the room and be cued.

Presentation content is the input most likely to cause trouble on the day, because it is the one that arrives last and from the least technical person in the building. Whether the deck comes down a cable from a presenter's own laptop or is played from the mix machine changes what happens when that laptop misbehaves — and it is worth deciding which, per session, before doors.

The vision operator is working to the same running order as everyone else, at a different granularity. A single agenda row — one 40-minute keynote — is a sequence of vision actions: hold on the wide, take camera two for the walk-on, lower third with the speaker's name, take the presentation feed on their first slide, and so on.

That means the vision position depends on programme information — session titles, speaker names, running times — that originates somewhere else and changes right up until the show. When a name is typed into the graphics preset by hand from a printed sheet, it becomes another copy of the truth, and it is the copy the audience will read on screen.

In practice the two are operated side by side, and the join between them is human. The vision operator has vMix on one screen and the running order on another, and the running order is what tells them a VT is coming, which camera the walk-on happens on, and what name goes on the lower third.

What makes that work or fail is whether the graphics presets were built from the same programme everyone else is reading. Lower thirds are usually prepared in advance as a list of names and titles, typed into vMix from a spreadsheet or a printed sheet. The moment a speaker is replaced, a title corrected or a session moved, that typed list is a stale copy — and it is the copy the audience reads on screen.

The discipline that avoids it costs nothing: build the lower-third list from the programme as late as is safe, name the export with the time it was taken, and have one person responsible for reconciling it after any change. That is the same rule as the printed running order — a stale copy you can date is manageable, an undated one is not.

To be direct about what ships today: EventBlok does not integrate with vMix. There is no plug-in, no control connection and no data link between the two, and everything in the section above assumes there is not one.

What EventBlok does today is remove the upstream half of the problem. The running order the vision operator works to, the names that go on the lower thirds, and the timings that decide when a VT rolls are all programme data, and EventBlok's job is to be the single place that data lives. The showflow holds the cue-level sequence, the agenda holds the programme it hangs off, and both read one record — so a speaker renamed at four o'clock is renamed everywhere the running order is read, including on the sheet the vision operator is typing from.

A WebSocket integration with vMix and with Bitfocus Companion is planned, which would populate lower thirds from the programme rather than having them typed in from it. It is planned and not built — it ships in MVP 2 if it ships — so nothing above depends on it, and no event should be specified on the assumption that it exists yet.

For which systems genuinely should share a record and which should be left alone — vision mixing is firmly in the second category — see what event production software should connect.