Timecode: how light lands on the music, and why 29.97 is a trap

A familiar story. At the dress rehearsal everything lined up: press Play on the timeline, press Play on the backing track, cues hit the accents. By the third show the light is a second and a half late by the end of the act, and nobody understands why.

The reason is boring: two different players count time with their own clocks. The crystal in the audio interface and the crystal in the computer are two crystals, and they drift apart. A second and a half over forty minutes is a 0.06% error — an entirely ordinary figure.

You don't fix this with care. You fix it by changing the scheme: light must not count time at all. It must follow the clock that audio dictates.

Three ways to bring the time in

MTC — timecode over MIDI. Almost any DAW sends it: Ableton, Reaper, Pro Tools. It arrives as quarter-frame messages: each frame is split into eight four-bit pieces, and a full timestamp assembles over two frames. That is where MTC's well-known two-frame latency comes from — and why it has to be compensated.

Art-Net Timecode — the same time, but as a network packet, on the same port 6454 as the light. Media servers send it (Resolume, Watchout, disguise), as do many audio consoles and "LTC to network" bridges.

LTC — timecode recorded as audio. The oldest and the most survivable method: it depends on neither network nor MIDI, and for the sound engineer it is just one more output you can plug into a line input.

How LTC sounds and why that works

LTC is 80 bits per frame encoded as biphase mark. The rule is simple: the level flips at every bit boundary, and if the bit is a one, it flips once more in the middle. In other words, the value of a bit is carried by the interval between transitions, not by where the signal sits relative to zero.

Two pleasant things follow. Polarity doesn't matter: flip the phase and the intervals stay the same. Level barely matters either — what counts is that transitions are distinguishable, not how loud they are. That is why LTC survives a cheap cable across half the stage where MIDI would have given up.

At 30 frames it runs at 2400 bit/s — audibly a fast, angry buzz. If you put the cable to your ear and hear that rattle, you have identified LTC.

And one non-obvious conclusion that cost us debugging time: when capturing LTC you must switch off all audio processing — echo cancellation, noise suppression, automatic gain control. All of them are designed for speech and work by reshaping the signal. For a voice that's an improvement; for timecode it destroys exactly the intervals the bits live in. Flux Lights disables processing explicitly, but if your audio driver does something of its own at system level, that is worth checking too.

The signal doesn't announce its frame rate — only the drop-frame flag. 24, 25 and 30 are indistinguishable by ear and by bits, so a human sets it.

29.97: an inheritance from black-and-white television

The most common trap. Where does a fractional frame rate even come from?

When colour was added to NTSC broadcasting, the colour subcarrier beat against the audio subcarrier and produced moiré on screens. Engineers shifted the frame rate by roughly one part in a thousand — from 30 to 30/1.001 = 29.97 — and the picture settled down. Compatibility with black-and-white sets survived, and the world inherited a frame rate that divides into nothing convenient.

Then comes the arithmetic. The timecode counter counts thirty frames per second while 29.97 arrive. Over an hour that accumulates 108 extra frames — 3.6 seconds of disagreement between the counter and the wall clock.

To make the counter agree with the clock again, someone invented drop-frame: two frame numbers are skipped at the start of every minute, except every tenth. Do the maths: 2 × 60 = 120 skips per hour, minus 12 not skipped (minutes 0, 10, 20, 30, 40, 50) — exactly 108. Those same 108. Numbers are skipped, not frames: the picture doesn't stutter, the counter simply jumps.

Practical conclusion: if your source runs at 29.97 and the light counts it naively as 30, by the end of a two-hour show you will be almost two seconds out. That is visible from the house. So we treat 29.97 as genuine drop-frame — and you can spot it by eye, because frames are separated by a semicolon: 01:02:03;04.

Show start

A sound engineer's track almost never starts at zero. It is usually 10:00:00:00 (a historical habit: an hour of run-up at the head of the tape) or an hour matching the act number.

The lighting timeline lives from zero, so you need an offset:

timeline position = timecode − "show start"

The "Take current" button sets the offset from whatever timecode is running right now. At rehearsal that is the fastest route: start the track from the right place, press the button, go.

What Flux Lights does when timecode disappears

Two things worth knowing in advance.

A source counts as lost after a quarter second of silence. At 24 frames per second or more that is already a definite stop rather than a lost packet: six frames should have arrived in those 250 ms.

The first frame after silence moves the cursor silently. This matters. If the sound engineer scrubbed the track to the middle of act two and we fired every marker from the beginning to that point, the entire cue list would flash on stage at once. So a locate or a resume moves the cursor without firing markers; moving forward in normal playback fires them as usual.

And third: while one source is running, the others are ignored. Two generators fighting over the cursor produce jitter that you then hunt all evening.

A two-minute check

Start the source and open the settings — the reader should run, with the source name and frame rate next to it. Park the track where you need it, press "Take current". Turn on "Follow timecode" and run a section: the cursor moves with the audio and markers fire where they did at rehearsal.

If the frame rate on screen doesn't match the one set in the DAW, stop there. A frame-rate mismatch doesn't show up in the first minute — it shows up in the finale.