What to save before you leave site

The rig worked. The client was happy. In four months the same event runs again, probably in the same venue, and the only record of how any of it was built is whatever you saved in the twenty minutes before the truck left.

Twenty minutes is enough, if you know what to spend it on.

The test for whether you have saved enough

One question: could someone else rebuild this rig from what you saved, without calling you?

Not “could you rebuild it” — you have the memory of building it, and that memory expires. Someone else, in four months, with the same gear list and your files.

That test rules out most of what people actually save, which tends to be the project file and nothing else. The project file is the least of it. It is the surrounding configuration that took the time.

What to capture, in order of how expensive it is to reconstruct

1. Photographs of the physical rig

The cheapest and most useful thing on this list, and the most often skipped.

• The patch. Every cable at the back of the rack, in focus, close enough to read the labels.
• Every screen showing configuration. The processor UI, display arrangement, device settings, the audio interface’s own display.
• The rig from the audience, and from the operator position.
• Anything you had to work out on site — a projector’s lens shift position, where the wall’s bottom edge actually sat, which output on the switcher the venue had wired to the foyer.

Photographs capture things you did not know were important. They take two minutes and they answer questions you cannot anticipate.

2. Processor and device configuration files

LED processor files, switcher state, projector settings, audio interface presets. These are configurations someone spent an hour dialling in, they live on hardware that will be re-hired to someone else next week, and they are almost never recoverable.

If the processor can export a file, export it. If it cannot, photograph every configuration screen. Do this before strike begins, not during — once panels start coming down, nobody is going to power a processor back up for you.

3. The canvas and mapping definition

The thing that makes the wall the right shape: canvas resolution, output regions, masks, warps, and which output went to which destination.

This is the part that should be a single file, and is worth checking that it actually is. In SpectraMap the canvas, its output regions and their transports save together, because splitting them across a project file and a set of preferences is how rigs come back half-configured.

Whatever you use, verify the save round-trips: quit, reopen, and confirm nothing was living in application state rather than in the file. Do this on site, while the wall is still up to prove it against.

4. Device and routing layout

Which physical input carried which source. Which channels of the aggregate device were which. What each virtual audio device existed for. Which display output went where.

This is knowledge that lives in a set of System Settings panes and one person’s head. Write it as a plain list:

SDI 1  → camera, stage left
SDI 2  → lectern laptop (via venue floor box 3)
Aud 1-8 → MOTU, 1=lectern 2=handheld 3-4=playback
Display 1 → projector (real output)
Display 2 → emulator → captured → SpectraMap
NDI out "Wall-L" / "Wall-R" → Novastar, ports 1 and 2

Six lines. Enormous value. If your routing lives in a tool that saves a configuration file — which is one of the arguments for making routing explicit at all, as in this piece on audio routing — save that too, but keep the plain-text version as well. Files need the software; a list needs nothing.

5. The things that went wrong and what fixed them

The most valuable half-page in the folder, and the one nobody writes.

“Venue floor box 3 is wired to the wrong patch panel — use box 5.” “The processor rejects 59.94, use 60.” “Screen Recording permission had to be re-granted after the OS update.” “The wall’s bottom row is blocked from rows 1–3, keep content above the middle.”

Every one of those cost you time to discover and takes ten seconds to write. Next time they cost nothing.

6. Content, and where it came from

The actual media, plus which version was used. “Final_v3_ACTUAL.mp4” is not a version record. Note what played, at what resolution, and who supplied it — the file you were sent at 4pm on show day is usually the one that ran, and it is usually not the one in the shared folder.

How to store it so it survives

One folder per event, named so it sorts and reads:

2026-09-15 ClientName - Annual Conference/
├─ README.txt          ← rig summary, gotchas, contacts
├─ photos/
├─ canvas/             ← mapping and playback project files
├─ device-config/      ← processor exports, switcher state
├─ routing.txt         ← the plain-text patch and device list
└─ content/

Two rules about where that folder lives:

• Not only on the show Mac. Show Macs get reimaged, sold, and dropped. Sync the folder somewhere shared before you leave, or at least before the next job.
• Somewhere a colleague can find it without asking you. If the archive requires knowing your naming habits, it is your archive, not the company’s.

The twenty-minute version

If the truck is loading and you have twenty minutes, in this order:

1. Photograph the patch and every configuration screen. Three minutes. Highest value per second on the list.
2. Export the processor and device configs. Five minutes, and impossible later.
3. Save the canvas file and verify it reopens. Three minutes.
4. Write routing.txt. Five minutes.
5. Write the gotchas into README.txt. Four minutes, while they are still fresh.

Content can be collected later from wherever it came from. Configuration cannot — it exists only on hardware that is about to go back to the warehouse.

Unattended rigs deserve particular attention here, because nobody is watching them during the show and nobody remembers how they were configured afterwards — an event photo slideshow is the common example.

Why this is a technical practice, not admin

The reason to do this is not tidiness. It is that the second time you do a show is where the margin is. The first time you are solving problems; the second time you should be loading a file. A rig that has to be rediscovered every year never gets faster, and the client is paying the same either way.

It also makes you replaceable in the specific sense that matters — someone else can take the job, which means you can take a different one. The next load-in is either archaeology or a file. That is decided in the twenty minutes before the truck leaves. For the other end of that cycle, there is the pre-show checklist.