BlackMatrix
An ATEM fleet as one router, with failover

What it does
An ATEM has no single thing called a router, so this treats every bus that takes one source at a time as a destination: the aux outputs, program and preview per ME, upstream and downstream keyer fill and key, every SuperSource box plus art fill and key, and every multiviewer window. On a Mini Extreme ISO that is 29 sources by 39 destinations, across as many switchers as you point it at.
Which sources are legal on which destination is read off the switcher rather than from a per-model table — every input reports an availability mask, and the app draws illegal cells hatched and refuses them server-side. That is what stops an aux output being routed back onto an aux bus, or ME 1's own output onto ME 1, without anyone maintaining a compatibility matrix.
The second half is protocol emulation. Each switcher also gets a Videohub Ethernet Protocol v2.3 server, so a hardware router panel, Companion's Videohub surface or Blackmagic's own software can drive the crosspoints without knowing an ATEM is on the other end.
An ATEM already serves that protocol itself, on TCP 9990 — and read back to back the two agree on every destination they share. What Blackmagic's own server offers is five outputs: Output 1, Output 2, Webcam Out, Program and Preview. This offers the other thirty-four. Use the switcher's own if five is what you need.
The third half is redundancy. A failover watch polls a machine — a TCP port, a URL, or a heartbeat it must be sent — and fires an ordinary salvo when it stops answering, which is the whole safety argument: the failover is the same button an operator can press by hand, so it can be rehearsed before the show rather than discovered during it. It will not fire until it has seen the machine working once, it starts disarmed, and it does not switch back unless you say what back means. For rigs where the media server drives the router itself — disguise's understudy sends matrix routing on failover, PIXERA fires a control action at a matrix switcher — the Videohub emulation is the target, and there is a plain-text line protocol on TCP and UDP for everything that can send a string but not speak Videohub.
There is a browser simulator with a device library, a mock fleet of three deliberately different switchers for development, desktop builds that bundle their own Node runtime, a container, and native iOS and Android shells that find the server for you — neither of which has yet run on a physical device. A real Blackmagic Videohub can sit in the same fleet as a device rather than only as a client, so one grid spans both.
Where it stands
Released at v0.3.0, which added the five command languages, and now run on a live event against a real ATEM rather than only checked on the bench. Before that it was checked against a real ATEM Mini Extreme ISO rather than only a simulator — which corrected the code rather than confirming it. Multiview windows 1 and 2 turned out not to be fixed to program and preview after 80 probe tests across all sixteen windows, and the switcher reports one multiview window while actually having sixteen. The multiview routing is hardware-verified; the aux buses are not — the aux-only availability bits were read off the masks and the aux-kind source IDs, never watched against what an aux output actually did. Its matrix was then served over the Videohub emulation as a 29x39 router. What has never happened is a real Videohub control panel driving it, and no real Videohub has ever been one of its devices. The macOS builds are signed and notarised; the Windows builds are unsigned, so SmartScreen warns once. macOS asks for local network access on first run — say yes, or no switcher is found.
Watch it running
Nothing loads from YouTube until you press play.Watch it there instead