How to Convert TCNet to SMPTE Timecode

What TCNet Actually Carries

TCNet is a network protocol from the Pioneer/AlphaTheta ecosystem for sharing deck state across a show LAN. It is well specified and easy to read once you know its shape, and it is routinely mistaken for timecode because it describes position.

On the wire it is UDP, little-endian, with a 24-byte header carrying an ASCII TCN magic at bytes 4–6, a node ID, a node type, and a sequence number. Discovery runs over broadcast on port 60000 — nodes announce themselves with OptIn and withdraw with OptOut — while Time packets arrive unicast on an ephemeral listener port.

The Time body describes eight decks at once:

That is more information than timecode carries. It is also, from a lighting console's point of view, completely unreadable.

Why Nothing Downstream Reads It

Consoles chase three things in practice: LTC as audio, MTC over MIDI, and Art-Net timecode over the network. GrandMA3, Eos, Titan and MagicQ all speak at least one. None of them speak TCNet, and there is no reason they should — it is a DJ-booth protocol that happens to contain a clock.

So the job is translation, and it is a genuine translation rather than a re-encoding. Three things have to be decided that TCNet never states.

Decision 1 — Which Deck Is the Show

TCNet hands you eight positions. Exactly one of them is the show, and the protocol has no opinion about which.

Pin a deck when the rig is built around a known layout — deck 1 is the playback machine, everything else is the DJ's. Simple, predictable, and it survives a chaotic booth.

Follow onAir when you want the clock to track whatever the mixer has live. Correct on a two-deck show with clean cuts. It becomes ambiguous the moment both decks are up in a blend, because two decks are on air and only one can be the clock.

Getting this wrong produces a clock that jumps backwards when a DJ cues an unrelated track on the spare deck — a fault that looks like a network problem and is not.

Decision 2 — A Frame Rate That Was Never There

currentTimeMs is milliseconds. Timecode is frames. Milliseconds contain no frames, so the converter invents the rate.

At 25 fps a frame is exactly 40 ms and the arithmetic is clean. At 30 non-drop it is 33.333… ms and already inexact. At 29.97 drop-frame, the rate most video-adjacent shows actually run, neither the frame duration nor the numbering is clean, and drop-frame's skipped labels have to be applied on top.

The practical rule: the converter owns the rounding, and every consumer must be told the same rate explicitly. Verify on each console rather than assuming inheritance — 29.97 against 30 drifts roughly a frame every 33 seconds, which is invisible at the top of a show and unmistakable by the end.

Decision 3 — What Happens When It Stops

A DJ pauses. A track ends. Someone unplugs the booth switch during changeover. The converter has to have an answer, and the answer should be rehearsed rather than discovered.

The subtle case is the one that breaks real shows: a master parked at one position keeps transmitting. Time packets arrive at their normal rate carrying an unchanged value. Any implementation that measures liveness by watching the value change concludes the source has died while its packets are still landing, and falls back to another clock mid-show.

Freshness must follow packet arrival, not value change. This is not hypothetical — CueSync shipped that bug and fixed it by emitting every accepted Time packet to freshness consumers rather than only the ones whose contents differ.

Doing It in CueSync

CueSync treats TCNet as one input among several and timecode generation as a separate output stage, so the conversion is a routing decision rather than a dedicated bridge.

Sources are ranked by priority — CDJ, then MTC, then LTC, then TCNet — with an internally generated clock appended last so it fills a vacuum but never pre-empts a live master. A forced-source override pins the input when you want the rig to stop negotiating.

On the output side it generates LTC, MTC, Art-Net timecode and TCNet. TCNet in, LTC and MTC out is one configuration of a general mux; the same setup also covers MTC in and Art-Net out, which is the other conversion people ask for.

Setup:

1. Put CueSync and the Pioneer gear on the same subnet, with broadcast permitted on UDP 60000. A managed switch that filters broadcast will make discovery fail silently.
2. Confirm the TCNet node appears in the input list — discovery precedes any clock.
3. Choose the authoritative deck, per Decision 1.
4. Declare the frame rate, per Decision 2, and set the same rate on every consumer.
5. Enable the sinks the rig needs — LTC to an audio output, MTC to a MIDI port, Art-Net timecode to the lighting network.
6. Pull the cable in rehearsal and watch what the console does.

The Honest Boundary

Converting TCNet to timecode gives a console a clock. It does not give it anything else TCNet knew — beat markers, deck state, on-air flags all stop at the converter, because timecode has nowhere to put them.

If what you want is cues that land on musical structure rather than at fixed wall-clock positions, timecode is the wrong carrier and the conversion is a detour. That is a different architecture: analyse the performance and fire cues from it directly, which is what audio-reactive cue triggering covers. Timecode is the right answer when the receiving system is already programmed against a timeline and simply needs to know where it is.

Further Reading

• Where Should Your Show's Timecode Come From? — four architectures and how to choose
• How to Send Timecode to GrandMA3 — transports, frame rates, failure behaviour
• Pioneer PRO DJ LINK Setup — the other way to read deck position
• CueSync Timecode Integration — supported sources and sinks