A control surface, a protocol reference and a Companion module
openRCS
The switcher still works. Its control software doesn't.
Analog Way's Midra and LiveCore processors are still in racks and still perfectly good. The software written to drive them isn't: it was built on browser and desktop runtimes that no longer exist, so on a current machine there is nothing to point at the box.
The processor never stopped listening. It speaks a terse ASCII protocol on TCP 10500 that has nothing to do with the client that shipped with it — so openRCS is a new control surface for it, written against the protocol rather than against the old application. Everything here is built on one Rust engine and one published reference.
The control surface
openRCS
A bridge server on the network, driven from any browser
A small Rust server holds one connection to the processor and serves a web UI to any number of browsers. It reads the variable table the device advertises and shows only the views that processor supports, so the same build drives a NeXtage and a Pulse2 without being told which is which.
- Workspace — sources, every screen editable side by side, and memories on one window-filling page
- Graphical layer editor, one-click layout presets, and preview-to-program takes with a transition time
- Shows — capture the device's whole state to a portable file and restore it; instant Confidence undo
- Plan mode — build a look with no device attached, then push it on connect
- Multiviewer, soft-edge and EDID designers, a full variable inspector and a raw-protocol console
- A tray launcher for macOS, Windows and Linux: enter the IP, pick the model, click Start
The reference
openRCS Protocol
Documentation, no code
The framing, the variable model and every variable for both platforms, written down — 1014 for LiveCore and 562 for Midra, grouped and tabulated, with the JSON tables beside the prose. It is what openrcs itself is written against, and it is published on its own so anyone else building for these processors doesn't have to start from nothing.
Try it before you own it
There is a browser demo of the control surface, behind “Try the live demo” on the card above — the real UI, unmodified, running against a device that exists only in the page. It is seeded from a recording of a real LiveCore session, so the variable table and the state it opens in are genuine.
It cannot reach hardware and doesn't pretend it can: a browser has no raw TCP socket, so the demo replaces the transport and keeps the app. Takes and memory save and recall are modelled; everything else echoes, and the footer says exactly what it can't show.
What it has actually been run against
Both families have been validated on real hardware — a NeXtage 16 on the LiveCore side and a Pulse2 on the Midra side. Device identity, framing, live layer control, takes, memories and EDID are all confirmed on the wire, including the places the two platforms disagree: Midra holds edits pending until a take commits them, LiveCore edits program directly.
One finding worth knowing if you drive these yourself: the device's own auto-take verb does not complete on the NeXtage tested here — it parks mid-transition and stays there. Takes are driven as a swept T-bar instead, in both the control surface and the Companion module, which does complete every time.
Per-variable ranges are strong guidance rather than a guarantee. Behaviour varies with model, firmware and whether an input has signal on it, so check against your own processor before a show depends on it.
The LivePremier mode is newer and in field testing. Reading has been exercised against two Aquilon C frames, and the AWJ operations underneath its take, cut and preset recall are confirmed on real hardware — by a separate test harness, so the wire is settled while the surface's own write path has only run against the simulator.
Midra 4K and Alta 4K shipped in v0.6.0 on 15 September 2026, and v0.7.0 the same day. The object model was read off a real Pulse 4K and the take, cut, recall and subscription operations were fired at it by a separate harness; openRCS's own surface for these — screens and auxiliaries with take, cut, T-bar and freeze, a layer editor on the screen's canvas with the unit's own pictures, preset banks that save and erase as well as recall, the quick preset, a multiviewer designer with its layout memories and the timers, audio routing, the device's configuration and canvases, inputs set up plug by plug with keyer and EDID, outputs with area of interest and custom formats, configuration backups and streaming, a stills page over the capture library, a system page and a raw AWJ inspector, and since v0.7.0 a Show page with every destination side by side, a cue list, a plan mode, autoscale on load, LUT libraries and soft edge — has been driven only against the vendor's Midra 4K and Alta 4K simulators, which never complete a capture, start a timer or a stream, or erase a custom format.
Not affiliated with Analog Way
Analog Way, Midra, LiveCore, NeXtage, Ascender, Pulse2 and the rest are their vendor's names, and none of this is endorsed by or connected to them. The protocol was worked out from device behaviour rather than taken from a published specification, and product names are used only to describe what the software talks to.
Help test it on real hardware
openrcs is built against device behaviour and a simulator; the most useful thing right now is time on real switchers.
Companion module
A Bitfocus Companion module on the same protocol, so takes, T-bars and memory recalls land on a Stream Deck instead of a browser tab.
Everything else
There's more where this came from
This is one corner of it. The full index covers audio, video, RF, content management, show control and the networking underneath.