How to Send Timecode to GrandMA3: LTC, MTC, Art-Net and TCNet

The Question Behind the Question

"How do I get timecode into GrandMA3" is nearly always a stand-in for a larger one: what is the authoritative clock for this show, and what happens when it stops? The protocol you pick matters much less than the answers to those two questions, so this guide covers the mechanics quickly and then spends most of its length on the parts that actually end shows.

GrandMA3 can run a timecode show two ways. It can generate the clock itself, which is the right answer for a show that starts when the console says it starts. Or it can follow an external source — SMPTE/LTC, MIDI timecode, or Art-Net timecode — which is the right answer whenever something else owns the timeline: a playback rig, a video server, a band on click, or a DJ.

The Three External Sources

SMPTE / LTC — timecode as audio

Linear timecode is an audio signal. It sounds like a modem and it behaves like sound, which is exactly why it has outlived several generations of more elegant alternatives: it travels down any path that carries audio, it does not care about IP addressing, VLANs, switch configuration, or whether the venue's network was set up by someone who has since left.

Route it from a spare output on your interface or playback machine to the console's timecode input. Keep it off the outputs feeding the PA — the sound is unmistakable and audiences do not enjoy it. Level matters: LTC decodes reliably across a wide range, but a signal squashed by a limiter or run through a compressor on the way out can smear the edges of the biphase encoding and produce intermittent decode failures that look like random dropouts.

Choose LTC when you are touring, when you did not configure the network, or when the show is important enough that you want the clock on infrastructure entirely separate from everything else.

MTC — timecode as MIDI

MIDI timecode carries the same hours/minutes/seconds/frames over MIDI as quarter-frame messages, with full-frame messages on locate. On a modern rig it usually travels over a virtual MIDI port between applications on one machine, or over a USB MIDI interface between machines.

Its advantage is that it costs nothing to set up. There is no cable to find, no output to spare, no level to check. For an onPC rig, a bench test, or a programming session, MTC is the fastest way to have a console chasing a clock in about a minute.

Its limitation is the quarter-frame mechanism: MTC transmits a full timecode position across eight messages spread over two frames, so a receiver is inherently a frame or two behind the transmitter and cannot resolve a position faster than that. For lighting cues this is inaudible and irrelevant. For anything demanding tighter-than-frame alignment, it is worth knowing the mechanism exists.

Choose MTC when the source and the console are on the same machine or the same short cable run, and when convenience matters more than isolation.

Art-Net timecode — timecode as a network packet

Art-Net carries a timecode packet type alongside its lighting data. If the console is already on your show network — and on any rig of size it is — the clock arrives on cabling you have already run and already tested.

The trade-off is that it now shares fate with that network. A broadcast storm, a switch that decides to reconverge, a well-meaning IT department, a loop introduced by someone patching in a laptop: all the ordinary hazards of a shared network are now hazards to your clock. On a properly isolated show network that is a small risk and Art-Net timecode is excellent. On a venue network you are borrowing, it is a real one.

Choose Art-Net timecode when the show network is yours, isolated, and known-good.

Frame Rate Is Where Shows Actually Go Wrong

The most common timecode fault is not a missing signal — a missing signal is obvious within seconds. It is a frame-rate mismatch, which is invisible at the top of the show and unmistakable by the end.

The pairs that catch people are 29.97 against 30, and 23.976 against 24. In both cases the two rates differ by a factor of 1000/1001, which works out to roughly one frame of error every 33 seconds. Three minutes in, you are a frame or two out and nobody notices. Forty minutes in, a cue that should land on a lyric lands on the wrong line.

Set the rate explicitly in three places — the generator, the console, and any third system chasing the same clock — and verify it on the console rather than assuming it was inherited. If you are working to picture, the video department's rate is not a preference you get to have an opinion about; take it from them.

One clarification worth internalising: drop-frame is not a different speed. 29.97 drop-frame and 29.97 non-drop run at the same rate; drop-frame skips certain frame numbers so that elapsed timecode matches wall-clock time over long durations. Mixing them produces labelling confusion, not drift. If your positions are wrong by a growing amount, the rate is wrong, not the drop-frame setting.

Decide the Failure Behaviour Before You Need It

Every timecode show eventually loses its source. A cable gets kicked, a playback machine hiccups, a network flaps, an operator stops the DAW to fix something and forgets what else was listening.

There are two reasonable responses and you must choose one deliberately:

• Freeze. The console holds the last state it reached. Nothing moves, nothing is wrong, and the failure is visible immediately to anyone looking at the stage. Good when a wrong look is worse than a static one.
• Freewheel. The chasing device keeps its own clock running at the last known rate and carries on as though the source were still there. Good for short dropouts on a show whose timeline is genuinely fixed. Dangerous when the source returns at a different position, because now two timelines disagree and the reconciliation happens live.

The distinction that makes freewheel safe rather than reckless is whether the operator can see that it is happening. A freewheeling transport that looks identical to a live one is a trap: the stage keeps moving, everything appears healthy, and the fault is only discovered when the positions have drifted far enough to be obvious. CueSync marks a freewheeling transport explicitly in Run Mode for exactly this reason — liveness is reported from frame arrival, not from the fact that a position number is still incrementing.

Where CueSync Fits

CueSync is not required to send timecode to GrandMA3, and a guide that pretended otherwise would not be worth reading. A DAW, QLab, a hardware generator, or the console's internal clock all do this job well, and for a fixed playback show one of those is usually the correct and cheaper answer.

CueSync is worth considering in three specific situations.

When the clock has to come from something that is not a timeline. A DAW can generate timecode because a DAW already knows where it is. A band, a DJ, or a vinyl set does not have a position to report. CueSync derives one — chasing CDJ position over PRO DJ LINK, or analysing live audio — and generates real timecode from it. That is how a live-sourced show gets a clock at all.

When you need to chase one format and emit another. CueSync's timecode input accepts CDJ position, MTC, LTC and TCNet, with priority-based source selection and per-source offsets; its output generates MTC, LTC, Art-Net timecode and TCNet. So a TCNet-only source can drive an LTC-only console, or a single LTC feed can be re-broadcast as Art-Net timecode to everything else on the network, without a second box.

When the same show also needs cues fired on musical structure. Timecode answers "where are we"; it has no opinion about what should happen there. CueSync's Theatre and Production editions run a timecode-anchored cue stack alongside triggers that fire on phrase boundaries, energy changes and hot cues — so the scripted parts of a show stay on the clock while the live parts follow the music.

Beyond timecode, CueSync speaks GrandMA3 in its own command vocabulary over TCP and UDP OSC, so it can take an executor or run a macro directly rather than only stamping a frame the console has to be pre-programmed against. That is covered in the GrandMA3 integration page.

A Working Checklist

1. Name the master. One device generates. Everything else chases. Write it on the plot.
2. Set the frame rate everywhere and verify it on the console, not on the generator.
3. Pick the transport for the room you are actually in — LTC when the venue is unknown, Art-Net timecode when the network is yours, MTC when it is all one machine.
4. Test a source drop before you need one. Pull the cable in rehearsal and watch what the console does. If you are surprised, fix it now.
5. Give the operator a liveness indicator that distinguishes a live clock from a freewheeling one.
6. Run the whole show once against the real clock. Frame-rate errors do not reveal themselves in a two-minute test.

Further Reading

• CueSync for Theatre Operators — timeline automation, cue stacks, and Run Mode
• GrandMA3 integration — command output, not just timecode
• How to Automate DJ Lighting with GrandMA3 — the reactive counterpart to this scripted workflow
• What Is Art-Net? — the protocol carrying the timecode packets above