Cinder: creative coding in C++ for bespoke live visual systems

Cinder is published by the Cinder project; the program itself lives at libcinder.org, and what follows is what it is for rather than what it ships.

Cinder is the outlier in this toolchain. Everything else here is configured; this is written. It is a C++ creative coding framework, and its presence on a production signals that somebody decided the required thing did not exist yet.

When code beats configuration

Three conditions justify it. The requirement is genuinely outside what existing tools express. Performance demands exceed what an interpreted or node-based environment delivers. Or the work is developmental, a technique being invented rather than applied.

Outside those, writing software is the expensive answer to a solved problem, and the discipline is in recognising which situation you are in before three weeks have gone.

What it costs after the show

The honest cost is not development time. It is that a compiled binary is opaque to everyone except its author, and touring productions change crew between legs.

Custom software that ships without documentation, a working build environment and someone else who has compiled it once becomes unmaintainable the moment its author is on another job. Productions that use code successfully treat that handover as part of the deliverable.

Where it still appears

Less often as a whole-show solution than it once did, because the standard tools have absorbed a great deal of what used to require code. It persists at the edges: unusual hardware, research-adjacent techniques, and generative work being developed rather than deployed.

For most reactive requirements a production will now reach for Notch or TouchDesigner first, and only drop to code when those genuinely cannot express the thing.

What it costs after the show

A compiled binary written for one production is an asset for exactly as long as its author is reachable. On the next routing it becomes a component nobody can modify, and the first time it needs a change the production discovers the cost of the decision it took a year earlier.

The mitigations are ordinary software practice and are usually skipped under show pressure: keep the tunable parameters outside the binary, document what it expects, and make sure one other person has built it from source.

Where it still appears

Rarely, and for good reasons when it does, a custom tracking integration, a bespoke generative system, a piece of hardware nothing else speaks to. Most of what used to require code is now covered by the systems tool or by real-time rendering, which is why the threshold has moved rather than disappeared.

How the toolchain divides between instruments and construction kits is set out on the toolchain; what any of it is playing is under real-time and VJ craft.

What it actually looks like on a production

Rarely a whole show, and almost always one component. A tracking integration that speaks to a camera system nothing else supports; a generative element with behaviour no product exposes; a bridge between two pieces of hardware that were never meant to meet. The binary does one job and hands its output to the rest of the chain as an ordinary source.

That framing is what keeps the risk bounded. A component can be replaced with a pre-render if it fails on the day; a show built entirely in code cannot, and the production discovers the difference at the worst possible moment.

Where it does appear, it tends to arrive through the same route: somebody prototypes an idea outside the show chain, the idea survives contact with a rehearsal, and only then is it built into something that has to run for ninety minutes without being watched.