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 easy to read once you know its shape, and it is routinely mistaken for timecode because it describes position.

Nodes announce themselves by broadcast on UDP port 60000 — the port a firewall or managed switch has to let through — and then stream their deck state to whoever is listening.

That state 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 the on-air flag 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

TCNet reports elapsed time in 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.

CueSync keeps following a paused or parked TCNet master: a paused deck does not drop the clock.

Doing It in CueSync

On a Pioneer rig, DJ and Production read each deck over PRO DJ LINK and send its playhead straight out as LTC, MTC, Art-Net timecode and TCNet, all at once. Theatre and Production also chase an incoming TCNet master and send it on in all of those formats at once, so the conversion is a routing decision rather than a dedicated bridge.

When several sources are present, CueSync follows the highest-priority one that is live; the priority list is in Settings → Timecode, and Force pins one input when you want the rig to stop negotiating. Chasing an incoming TCNet, LTC, MTC or Art-Net master is part of Theatre and Production; every edition generates timecode, and DJ and Production also send each CDJ's playhead out as timecode.

On the output side it generates LTC, MTC, Art-Net timecode and TCNet. TCNet in, LTC and MTC out is one configuration among several; 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.

What Timecode Carries

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: read the track's structure 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