Guide · Automation

Make tally drive your presentation software.

Two open interfaces sit next to each other in most venues and have never been introduced: the tally state Airlive already broadcasts, and the HTTP API ProPresenter has shipped since 7.9. Wiring them together is a small script — and it automates the thing a volunteer operator most often forgets.

The gap worth closing

In a typical room the camera side and the presentation side know nothing about each other. Someone cuts to a camera; someone else, on a different machine, has to remember to change the look, clear the lower third, or drop the lyrics. It works until the service runs long and attention slips — which is exactly when it matters.

Both halves already publish their state. Nobody has connected them, and there's no technical reason for that.

What each side actually offers

Airlive side

The protocol's control channel is bidirectional JSON. A receiver sends setCue with none, preview or program; the camera pushes a full state snapshot on connect and after every change. So the program state is readable and writable, live.

ProPresenter side

Since 7.9 there is a documented HTTP API: standard request/response for commands, plus subscriptions that hold a connection open and stream JSON as things change. You can trigger slides, change looks, and read what's currently live.

To be precise about what the API is. ProPresenter's API is for control — slides, triggers, state. It is not a video input. Video still arrives over NDI, Syphon or a capture device, as described in the venue screens guide. This automation rides alongside the video path, it doesn't replace it.

The shape of the script

You are writing a small always-on process that watches one thing and calls another. It doesn't need a UI, and it should not sit in the video path.

  1. Know which camera is live. Either read it from your switcher, or connect to each camera as a receiver in control-only mode and watch the cue state arrive.
  2. Map cameras to intentions. A small table: camera 2 means the pulpit, camera 3 means the wide. Intentions, not slide numbers — slide numbers change every week.
  3. Call ProPresenter on change. When the live camera changes, fire the matching trigger. Debounce it: a fast double cut should not fire twice.
  4. Fail quietly. If ProPresenter is closed or the network hiccups, log and keep running. An automation that crashes the show is worse than no automation.

What it buys you

  1. Lower thirds that can't be late. Cut to the camera on the speaker and the name card appears with the shot, not four seconds after it.
  2. Lyrics that get out of the way. When a close-up goes live, drop to a clean look automatically; restore on the wide.
  3. A stage display that follows the show. Confidence monitors can reflect which camera to look at, without anyone narrating it over comms.
  4. One less thing for a volunteer to hold. This is the real return. The system remembers, so the person doesn't have to.

Where to be careful

Automation is only welcome when it is predictable. Three rules that keep it that way:

  • Keep a manual override. The operator must be able to take back control instantly, without stopping your script.
  • Never automate anything irreversible on air — clearing a playlist, ending a stream. Trigger looks and lower thirds, not destructive actions.
  • Rehearse it cold. Run a full service in an empty room before it runs in a full one.

We're not shipping this

That is deliberate. Every venue's presentation setup differs enough that a first-party integration would be wrong for most of them and hard to configure for the rest. Publishing the interface and letting you write the fifty lines that fit your room is the honest version — and with the specification in hand, an assistant can write most of it.

If you build one, tell us. If enough rooms converge on the same behaviour, that's a signal worth acting on.

All articles