Stoatworks Labs

About

Not a startup. A technician with a text editor.

Stoatworks Labs is one AV technician writing the software our industry never got round to writing — and, increasingly, designing the hardware to go with it.

You know the problems. Frequency coordination that lives in three incompatible file formats and a spreadsheet somebody emailed round in 2019. A switcher fleet you configure one unit at a time, by hand, on a flight case, at 02:00. An amplifier with a perfectly good control protocol and absolutely no way to talk to anything you own. A cue player that costs more than the show.

None of these are hard problems. They are just problems nobody with the right combination of stage time and patience has sat down and fixed. So they get fixed here, one at a time, and then given away.

What that covers

33 projects so far, across seven disciplines — because the job does not respect departmental boundaries and neither should the tools.

  • Audio — Cue playback, DSP, amplifier and console control.
  • Video — Switchers, routers, media servers and stream transport.
  • Lighting — DMX, Art-Net and sACN distribution.
  • RF & Wireless — Radio mic coordination, monitoring and licensing.
  • Content Management — Getting presenter files in, converted, and on screen.
  • Show Control — OSC, MIDI, MSC and Companion integration.
  • Networking & Infrastructure — The plumbing under a multi-room event.

On the use of AI

Most of this code is written with AI assistance, directed and reviewed by a human. We say so on every repo, in the README, before you read a line of it.

That is not an apology and it is not a disclaimer bolted on afterwards. It is the reason one person on the road can ship this much across this many disciplines. But it also means the same thing it means for any code: review it yourself before you put it in front of an audience. We have found and fixed real bugs that a confident-sounding first draft sailed straight past — that is exactly why the verification work in each repo exists, and why "tested against real hardware" is stated separately from "builds clean".

Where it runs

Several of these tools have sat on a rack in a theatre. Several have not, and say so. The distinction is kept deliberately visible — on thehardware pages especially, where a board can be fab-ready, DRC-clean and completely unproven at the same time.

How the work gets made

  1. 01

    It starts on a gig

    Every tool here began at the exact moment something should have been easier — a format that would not import, a fleet that had to be configured one box at a time, an amp with a perfectly good protocol and no way to talk to anything.

  2. 02

    No account, no cloud, no phone-home

    These run on your machine, on your network, on your show. Nothing needs a login, nothing needs the internet, and nothing reports back. A tool that stops working when the venue WiFi does is not a tool.

  3. 03

    Honest status, always

    Every repo says plainly what has been tested against real hardware and what has only ever run in simulation. "Verified" and "assumed" are different words and we use them differently.

  4. 04

    Open by default

    Public and MIT-licensed unless there is a specific reason not to — usually protocol work that is still settling, or a client design that is not ours to publish.

  5. 05

    Documented for the next person

    Every project carries a doc explaining why it is built the way it is, what the traps are, and which decisions are load-bearing. Including for the AI that helps write it.