Cable list
It is the sheet in your hand while you pull cable: one label per run, where it starts, where it lands, what it carries and how long it is. The rest of the load-in depends on it.
What it must contain, and nothing more
Six columns are enough: the label written at both ends of the cable, the source device and port, the destination device and port, the signal type, the connector and the length. A list carrying less sends you back to the diagram mid-pull; a list carrying more can no longer be read on your knees under a stage with a head torch.
Connector and signal are two columns, not one. An RJ45 can carry Dante, Art-Net or a control link: knowing you need an RJ45 says nothing about what runs through it, and that confusion is how a DMX node ends up patched into an audio switch.
The label is the only thing that survives the show
A cable with no label does not exist at load-out: it lands in the wrong crate and is missing at the next load-in. The label has to be unique across the production, stable from one revision to the next, and short — it gets written on gaff tape with a marker, not printed on an office sticker. A label that changes because a device was added is a label that lies about a cable already marked.
Why a hand-typed list is wrong within hours
The diagram moves: one more monitor wedge, a console swapped for another model, a stage box moved to the other side. Every change ought to reach the spreadsheet — and does not, because nobody has time to reopen it between two calls. On the day, two documents contradict each other and the one on top wins. The only way out is not to have two documents: the list follows from the diagram, it does not copy it.
What Technipatch derives, on every change
Here is the example project’s list, exactly as it comes out — these rows were not written for this page, they are the same computation the app runs on screen and the PDF prints. It exports to CSV, column by column, to hand to a rental house or paste into a prep sheet. And the other way round: an equipment list already kept in a spreadsheet imports from CSV, so you do not re-place fifty devices by hand just to see what it looks like.
| Label | Source | Destination | Signal | Source connector | Length |
|---|---|---|---|---|---|
| A01 | Lead vocal · Out | Stage box · IN 1 | Microphone (analogue) | XLR 3-pin F | 10 m |
| A02 | Snare · Out | Stage box · IN 2 | Microphone (analogue) | XLR 3-pin F | 10 m |
| A03 | FOH console · Omni OUT 1 | FOH amplifier · IN 1 | Line (analogue) | XLR 3-pin F | 3 m |
| A04 | FOH console · Omni OUT 2 | FOH amplifier · IN 2 | Line (analogue) | XLR 3-pin F | 3 m |
| A05 | Keys DI · Out | Stage box · IN 3 | Microphone (analogue) | XLR 3-pin F | 12 m |
| A06 | FOH amplifier · Speaker out 1 | Mains stage right · Speaker in | Speaker line (amplified) | speakON NL4 | 15 m |
What gets checked before you even fetch the cable
A correct list is no help if the link itself is impossible. The engine refuses the connection as you pull it, with its reason: incompatible signal, incompatible connector, two outputs facing each other, port already taken. It is a written rule engine, not a language model — the same link always returns the same verdict, and the refusal says what to do about it.
The canvas is already open
Drop five devices, pull cables between their ports: the cable list, the patch sheet and the equipment list fill themselves in while you draw. No account, no card.