TouchDesigner: node-based systems for live visuals and control

TouchDesigner is published by Derivative, whose documentation lives at docs.derivative.ca, and what follows is what it is for rather than what it ships.

TouchDesigner occupies the position in the toolchain that nothing else quite covers. The playback tools are instruments with strong opinions about what a show is. This one has almost no opinion, which makes it capable of anything and responsible for nothing.

Node-based thinking

A patch is a graph. Operators generate, transform, combine or output, and connections carry data between them. The picture on screen is a consequence of the graph rather than a thing that was authored directly.

This suits problems that are structural rather than pictorial: route this input to that parameter, scale it this way, hold it when the signal drops, send the result to three places. Those are the problems a large live system is actually made of.

Control data as a first-class input

What distinguishes it in a live rig is how naturally it ingests control signals. Timecode, MIDI, OSC, DMX, network messages, audio analysis and tracking data all arrive as values that can drive anything.

That is why work with genuine interactivity (installations, tracked objects, audience-responsive pieces) tends to be built here rather than in a playback environment.

The maintenance risk

The honest cost of a bespoke system is institutional. A patch is precisely as maintainable as its documentation, and touring crews change between legs.

Productions that rely on custom systems and survive are the ones that treat the patch as a deliverable (commented, structured, handed over) rather than as one engineer’s working file. Productions that do not, discover the problem in a different country.

How it fits alongside the rest

Most commonly as a specialist stage rather than the whole rig: it handles the bespoke part and passes output to the playback layer, or drives surfaces directly where the mapping is unusual. Where the requirement is purely generated imagery rather than system behaviour, Notch is frequently the lighter answer.

The maintenance question nobody asks early

A custom network is written by somebody, and that somebody is frequently not on the next routing. A patch that only its author can safely modify is a liability disguised as a capability, and the liability arrives at the least convenient moment.

Productions that use it well treat it as software: the network is documented, the parameters that are meant to be touched are separated from the ones that are not, and somebody other than the author has opened it before opening night.

Where it belongs in a rig

Upstream of the instrument. The reliable arrangement is that the custom part generates or transforms something, hands it over as a normal source, and the clip-and-layer instrument plays it. Asking a construction kit to also be the surface an operator drives during the show is the arrangement that goes wrong.

It commonly feeds real-time content its control data and sits alongside the mapping stage. The far edge of the same spectrum (where configuring is harder than writing) is code. The spectrum itself is described on the toolchain.

A last practical note: it is frequently the piece that makes a rig demonstrable early. Because it connects things rather than producing them, a rough network can stand in for hardware that has not arrived, which lets the rest of the chain be tested weeks before the real components exist.