Stoatworks Labs

About

It's just me, really.

Stoatworks Labs is one AV tech who does sound, vision and RF for a living and writes software in between. Lately I've started designing the hardware to go with it as well, which nobody saw coming, least of all me.

You'll know the sort of problem. Frequency coordination spread across three file formats that don't agree with each other, plus a spreadsheet someone emailed round in 2019. A rack of switchers you set up one at a time, by hand, on top of a flight case, at two in the morning. An amp with a perfectly good control protocol that refuses to talk to anything you own. A cue player that costs more than the show does.

None of these are hard problems, really. They just needed someone with enough stage time and a slightly unhealthy amount of patience to sit down and sort them out. So I sort them out, one at a time, and give them away.

What that covers

220 projects so far, across nine areas. Most crew I know do at least three of these jobs, so the tools ended up all over the place as well.

  • Audio — Cue playback, DSP, amplifier and console control.
  • AV Systems — Switchers, routers, media servers and stream transport.
  • Video FX — Effects, generators and plugins that run inside somebody else's host.
  • 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.
  • PowerPoint — Decks: their fonts, their exports, and the screens they end up on.
  • Show Control — OSC, MIDI, MSC and Companion integration.
  • Networking & Infrastructure — The plumbing under a multi-room event.

About the AI

I write most of this code with Claude, Anthropic's AI, and I direct it, read it and test it. Every README says so at the top, before you get anywhere near the code.

It's the only way one person who's out on gigs most weeks gets this much made. It also means you should treat it like any other code you found on the internet, and check it before you put it in front of an audience. Claude has written me some extremely confident bugs, and catching them is why every repo keeps "tested on real kit" separate from "it compiles".

Where it's been used

Some of these tools have done shows on a rack in a theatre. Some haven't left my desk yet, and their pages say so. That goes double for thehardware, where a board can pass every design check going and still never have had power through it.

How I go about it

  1. 01

    It starts on a gig

    Pretty much everything here started with me on a job, muttering at something. A file that wouldn't import, a rack of switchers that had to be set up one at a time, an amp that could talk perfectly well but only to its own software.

  2. 02

    It works without the internet

    These run on your machine and your network. You don't need an account, and nothing phones home. Venue WiFi is lovely when it works, and I've never once wanted a show to depend on it. The browser tools are the same: no cookies, no tracking, and your files stay in the tab.

  3. 03

    It says what's been tested

    Every repo says what has run on real kit and what has only ever run on my desk. If I haven't tried something on a show, I'll tell you, because I'd much rather undersell it than have you find out at doors.

  4. 04

    It's open

    Everything is public and MIT-licensed unless there's a good reason not to, which usually means protocol work that's still settling down, or a design that belongs to a client.

  5. 05

    It's written down

    Each project has notes on why it's built the way it is and where the traps are. Partly for the next person, partly for the AI that helps write it, and mostly for me in six months, when I've forgotten all of it.