The systems you will meet, and when to write your own

Every product on this page exists because somebody had your problem and solved it for a living. Most of the time the right answer is to buy it. The skill this course is actually for is telling the difference, and being able to say why in a room where money is being spent.

A technical director is not paid to write code. They are paid to decide what gets bought, what gets built, what gets hired, and who answers for it at 23:40. This page is the reference behind that decision: what each family of product is really doing, where its edge is, and what happens when you step over it.

Read this as a map, not a shopping list. Products change, versions change, and a price you remember is a price you will be wrong about in front of a client. What does not change is the shape of each category and the reason it exists.

The buy-or-build test, in five questions#

Ask them in this order. The first "no" usually ends the discussion.

1. Does a product already do this, within twenty percent? If yes, buy it and adapt the show. The twenty percent you would have written is almost never worth the year of maintaining it.
2. Who fixes it at 23:40 on the second preview? If the answer is one named person and that person is on holiday in November, you have bought a risk, not saved money.
3. What is it worth to be able to change it? Some shows live or die on a thing no product does. That is the case where building is not a saving, it is the only route.
4. What is the total, including the parts nobody counts? Your time. The rewrite when the OS updates. The handover document. Training the operator. Spares. Two of everything, because one of everything is not a system.
5. What is the failure mode, and is it worse than the product's? A product fails in a way its support desk has seen before. Yours fails in a way nobody has.

The honest summary. Build when the thing is small, specific to this show, and would be a compromise as a product. Buy when it is a category. Glue when the products exist but do not talk, which is most of the time, and which is where a technical director who can write code earns their place in the room.

Lighting control#

What every one of them is doing underneath: keeping a large table of channel levels, resolving which of several sources owns each channel right now, and pushing that table onto a wire 40-ish times a second. That is the whole architecture, and the same one your block program in the lab has.

Where you write code around them. Not inside. You write the thing that feeds them: a script that turns a spreadsheet into a patch, a tool that diffs two show files, an OSC bridge from a sensor. Every desk on this list speaks OSC or Art-Net or both, and that is your door in.

The case study worth doing in class. A festival with thirty acts, each with a patch supplied as a spreadsheet in a different shape. Retyping is four hours per act, wrong twice. A script that normalises them and emits the desk's import format is about ninety lines and pays for itself on act three. That is the break-even calculation from Class 1, on real numbers.

Sound and cue playback#

QLab is the one to understand properly, because it is where most of your OSC traffic will come from and go to. A QLab cue can send an OSC message, and QLab will act on one it receives. That single fact is how a lighting desk starts a video, how a sensor triggers a sound, and how the Pi you built in the boards page joins a show that was not designed around it.

Where you write code around it. A script that builds a workspace from a cue sheet. A bridge that turns a MIDI footswitch into OSC. A watchdog that notices playback has stopped and tells somebody.

Video and media servers#

The distinction that matters. disguise and Watchout are products: you configure them. TouchDesigner and Isadora are environments: you build in them. The second kind is where a technical director who can program becomes a designer's most valuable collaborator, and it is exactly the kind of visual programming Class 2 puts next to text: a patcher is a program, drawn.

Show control and integration: the glue layer#

This is your category. It is the one where the thing you need does not exist as a product because it is specific to your building and your show.

Companion deserves a paragraph on its own. Before you write a bridge, check whether Companion already has a module for both ends. It very often does, it is free, somebody else maintains it, and choosing it over your own script is the mature answer even though it is less fun. When it does not have your device, writing a Companion module is a smaller, better-supported job than writing a standalone tool, and somebody else gets the benefit.

Where the line is. Anything that moves a person, holds a load over a head, or is part of a life safety system is not a place for a general-purpose computer or for your own code. It is a PLC, a certified controller, and an interlock chain that works with every processor in the building switched off. This is not conservatism, it is the law and the physics.

The pattern behind all of them#

Every product on this page is the same five parts in a different proportion:

1. A model of the world. Channels, cues, layers, devices, timecode. Learn this first and the interface stops being arbitrary.
2. A scheduler. Something that decides what happens next and when, usually 25 to 60 times a second.
3. An output stage. DMX, sACN, audio, pixels, HDMI, a relay.
4. A persistence format. The show file, which is the thing that actually gets carried to the next venue and the thing you should be able to read.
5. An interface. Which is what everybody argues about and which matters least.

When you build, build the same five parts, and be explicit about each one. A tool that has a scheduler you did not know you were writing is a tool that will be late in a way you cannot debug. This is the architecture your capstone is assessed against, and it is why Class 6 asks for a failure mode in writing.

Six case studies, for the room#

Each of these is a real shape of problem. Argue them in class before you look at the answer, because the arguing is the assessment.

1. The patch that arrives as a spreadsheet#

Thirty acts, thirty formats, four hours of retyping each. Build. It is small, specific, and no product wants it. Ninety lines, and Class 3 is the class where you write it.

2. The projection has to land on a curved set that does not exist yet#

Buy, or hire. disguise exists because this is genuinely hard, and the pre-visualisation is what lets you commit to a design before the build. Writing your own mapping engine to save a hire fee is how a season gets lost.

3. The DSM wants one button that starts sound, video and lights together#

Glue, and check Companion first. If both ends speak OSC and Companion has modules, you are done in an afternoon with nothing to maintain. If they do not, a fifty line bridge on a Pi is the answer, and it needs a failure mode: what happens when one of the three does not acknowledge.

4. Forty performers each carrying a light that has to change on cue#

Build, with the arithmetic from the boards page written down. The commercial products exist and they are excellent and they cost more than the whole production. Build it, then be honest about the radio in a full house and design what a dropout looks like.

5. A permanent installation that has to run unattended for three years#

Buy hardware built for it. An Alcorn McBride or a PLC boots in a second, has no OS to update, and was designed by people who have been called out at 03:00. Your Pi is a lovely prototype and a poor twenty-year answer, and the honest version of that sentence in a client meeting is worth more than the contract you would have won by not saying it.

6. The automation cue has to stop if somebody is in the wrong place#

Not your code, at all. Safety-rated hardware, a certified integrator, an interlock chain, and a signed-off risk assessment. Your code may know about it. It may never be what enforces it.

What this means for what you learn#

You will spend most of your career specifying, integrating and verifying systems other people built, and occasionally writing the small specific thing nobody sells. Both halves need the same skill: being able to read a system, name its model, find its edge, and say out loud what it does when it fails.

That is why this course is about reading code as much as writing it, and why the capstone is marked on the handover as much as on the build.

Numbers from this page#

Where this goes next#

• Class 4 is where the buy-or-build argument meets AI-generated code and the same question about who answers for it.
• The boards page is the same decision one layer down, in parts and prices.
• The model box is where you build a small version of every layer on this page and watch them fail.
• Show Networking and Control Systems is eight sessions on the protocols these products speak to each other, taken as an elective.