What LTC Timecode Is, and Why Your Show Suddenly Feels Like It Has a Brain

First, tiny nerd note: LTC stands for Linear Timecode, so saying “LTC timecode” is technically like saying “ATM machine.” But production people say “advance the downstage kabuki into the spicy blackout,” so honestly, we’re fine.

In live concerts, LTC is one of the most common ways to make a bunch of different show systems follow the same clock. Playback, lighting, video, lasers, automation, pyro, cameras, and other departments can all listen to that clock and know exactly where they are in the show.

Think of LTC like the click track’s responsible older sibling. The click tells the band where the beat is. Timecode tells the entire production where the show is.

The setup problem

Modern concerts are not just “band plays song, lights look cool.” A single chorus might have playback tracks, a lighting cue stack, video content, camera cuts, laser hits, scenic automation, and maybe a confetti moment that costs more than someone’s first car.

All of those departments need to agree on one question:

“Where are we right now?”

Without a shared time reference, every department is basically holding a stopwatch and hoping they pressed start at the same moment. That can work for simple shows, but once the production gets more complex, it gets sketchy fast. Lighting might fire a big chorus look too early. Video might hit the drop late. Lasers might be vibing in the wrong section of the song. Not ideal. Very “group project energy.”

LTC solves that by giving everyone a shared clock to follow.

What LTC actually is

LTC is an audio signal that carries time information. It sounds like digital noise if you listen to it directly, which you absolutely do not want in the PA unless chaos is your brand.

Inside that little angry robot noise is a time address that looks like this:

HH:MM:SS:FF

That means:

• Hours
• Minutes
• Seconds
• Frames

A receiving device listens to the LTC audio signal, decodes the time, and locks its own timeline to it. So instead of the lighting console guessing when the bridge starts, it can say, “Cool, we are at 01:12:34:18, so I know exactly which cue should be happening.”

It is not music. It is not MIDI. It is not magic, although when it works well, it does feel suspiciously magical.

Timecode is one long 24 hour ruler

The easiest way to understand timecode is to imagine one giant 24 hour ruler laid across the whole day.

It starts here:

00:00:00:00

And it runs all the way up to:

23:59:59:FF

Then it wraps back around to zero.

That is the whole universe of timecode: one 24 hour timeline. Every song, intro, interlude, video roll, walk-on, encore, and emergency “please stall while we fix something” moment can live somewhere on that ruler.

For concert workflows, you usually do not start every song at zero. That would be like putting every song in the same folder and naming all of them “final_final_really_final.wav.” Technically possible. Emotionally damaging.

Instead, productions usually place songs at different areas of the 24 hour clock. That way, every chunk of the show has its own clean address range.

What a timecode offset is

A timecode offset is the starting time assigned to a song or section.

Let’s say your playback session starts Song 1 at:

01:00:00:00

That means when Song 1 begins, the timecode does not start at zero. It starts at one hour. The song might run from 01:00:00:00 to 01:04:12:10.

Then Song 2 might start at:

01:10:00:00

Song 3 might start at:

01:20:00:00

That gap between songs is intentional. It gives everyone breathing room. It also makes programming cleaner because each song has its own neighborhood on the 24 hour ruler.

Offsets are like putting each song in its own parking spot. You could cram every car bumper to bumper, but why would you choose pain?

How productions commonly use offsets

In a real concert workflow, offsets are usually planned before serious programming begins. The playback tech, lighting programmer, video team, laser programmer, and sometimes automation or pyro departments all need to know where each song lives.

A simple show might use offsets like this:

• 01:00:00:00 Song 1
• 01:10:00:00 Song 2
• 01:20:00:00 Song 3
• 01:30:00:00 Song 4

That gives each song a ten minute block, even if the song is only four minutes long. The unused space is not a problem. Timecode is 24 hours long. You have room. Be generous. Live production already has enough stress without making your timecode map look like a game of Tetris.

Some productions use larger offsets for different show sections:

• 01:00:00:00 Main set
• 02:00:00:00 Acoustic section
• 03:00:00:00 Medley
• 04:00:00:00 Encore
• 05:00:00:00 Special one-off content

This makes it easier for humans to navigate. If the lighting director says, “We are in the 03 hour,” everyone knows they are probably dealing with the medley section. It turns the show into a map instead of a mystery novel.

Why live productions use LTC

LTC is useful because it lets departments build detailed programming that follows playback accurately every time.

For lighting, it can trigger cues with frame-level precision. For video, it can lock media playback to the song arrangement. For lasers, it can keep beam hits and effects aligned with musical moments. For automation, it can help scenic moves happen at the correct point in the track. For cameras or broadcast workflows, it can help synchronize recordings and post-production timelines.

The big idea is consistency. LTC lets the show repeat the same way every night, while still allowing humans to operate creatively on top of it.

A good metaphor is a train track. The train is the song. Timecode is the rail. Lighting, video, lasers, and automation are all riding along that same rail, hitting their stations at the right time. The operators are still driving the vibe, but the timing foundation is locked.

Or, for the Gen Z department: timecode is the shared location pin for the whole production. Everyone opens the same map and stops wandering around like, “Wait, are we at the bridge or the final chorus?”

What LTC does not do

LTC does not automatically make a show good. It does not store cues, design lighting looks, choose video content, fix a bad arrangement, or save a rehearsal process that has gone fully feral.

It also does not replace operators. Most live productions still have people making decisions in real time. A lighting director may still call spots, ride bumps, fire audience looks, adjust front light balance, and adapt to the artist. A video director may still cut cameras live. Timecode simply handles the repeatable timing backbone.

Think of it as cruise control, not autopilot. Very helpful. Still requires a driver.

The only caveat is that it is possible to program out a fully timecoded show that runs itself, but it just requires a fairly controlled environment, such as the same exact lighting package every night.

Where LTC comes from in a concert rig

In many music workflows, LTC is generated by the playback system. That might be a DAW, a dedicated playback rig, or a show-control system. The LTC is usually routed out of an audio output, often on its own channel, and sent to whatever devices need to follow it.

A common setup might look like this:

• Playback rig generates LTC
• LTC travels as an audio signal
• Lighting console receives LTC
• Media server receives LTC
• Laser system receives LTC
• Other show-control devices receive LTC as needed

Because LTC is audio, it needs to be treated like audio. It needs the right routing, the right level, and a clean signal path. If the LTC channel is muted, patched wrong, distorted, summed to mono in a weird way, or accidentally sent to the PA, the show may have a bad time.

Pro tip: label the LTC line clearly. Future you deserves peace.

Frame rates, without the migraine

The last part of the timecode address is frames. That is the FF in HH:MM:SS:FF.

The frame rate tells us how many frame numbers exist inside each second. Common timecode frame rates include:

• 24 fps
• 25 fps
• 29.97 fps
• 30 fps

For live concerts, the frame rate decision should usually be based on the video world first. Lighting and lasers can usually follow whatever is chosen, but video systems care deeply about frame rate. Video people are not being dramatic. Well, not only dramatic. They are protecting the content pipeline.

24 fps: film and camera-style workflows

24 fps is historically associated with film and cinematic camera workflows. If a production is heavily camera-based and shooting at 24 fps, or if the main content pipeline is built around 24 fps, then 24 fps timecode may make sense.

In concert touring, 24 fps is less common as the default show-control choice unless there is a strong camera, cinema, or post-production reason for it.

If someone says the cameras are “24,” it is worth confirming whether they truly mean 24.000 fps or 23.976 fps. Those are not the same thing, and the difference can matter in video workflows. This is where you let the video engineer cook.

25 fps: Europe and 50 Hz land

25 fps is common in Europe and other regions built around 50 Hz video and power standards. It comes from PAL broadcast history and still appears in a lot of European broadcast, television, and video production workflows.

If your production is in a 50 Hz environment, using 25 fps timecode often fits nicely because it lines up cleanly with 50 fps video systems. One timecode frame can correspond to every two video frames at 50 fps.

For European broadcast-adjacent work, festivals with broadcast trucks, or content built at 25 or 50 fps, 25 fps is often the grown-up choice.

30 fps: US live production and 60 fps workflows

30 fps is common in US live production workflows, especially when the show is built around 60 fps video content or systems.

If your video walls, media servers, or content pipeline are running at true 60 fps, then 30 fps timecode is usually a practical fit. One timecode frame can line up with every two video frames. Clean. Simple. We love a non-messy queen.

This is why many concert productions in the US choose 30 fps non-drop for show control. It is straightforward, widely supported, and friendly to lighting, playback, lasers, and media servers.

29.97 fps: the broadcast gremlin that still matters

29.97 fps exists because of legacy NTSC color television standards in North America. It is very close to 30 fps, but not exactly 30 fps. That tiny difference matters over time.

You will still see 29.97 in broadcast, television, livestream, recording, and post-production workflows, especially when the production is tied to 59.94 fps video rather than true 60 fps.

If the video truck, record pipeline, or broadcast team says the show is 59.94, then 29.97 timecode may be the correct match. Do not just round it to 30 because it feels cleaner. That is how sync gremlins are born.

Drop frame vs non-drop frame

Drop frame sounds terrifying, but it does not drop actual video frames. It drops certain frame numbers from the timecode count so the timecode clock stays aligned with real elapsed time when using 29.97 fps.

At 29.97 fps, if you count timecode like it is exactly 30 fps, the timecode slowly drifts away from wall-clock time. Drop frame fixes that by skipping specific frame numbers at specific minute marks. Again, no picture frames disappear. Only numbers are skipped.

Drop frame is mostly used in broadcast and television workflows, especially when exact program timing matters. For example, if a TV program needs to be exactly one hour in real time, drop frame helps the timecode duration match the clock on the wall.

Most live concert show-control workflows do not use drop frame. Lighting, lasers, playback, and media server programming usually prefer non-drop because it is simpler and less annoying to manage. Unless broadcast, recording, or post specifically requires drop frame, non-drop is usually the move.

In casual production language, you might see these written as:

• 30 ND for 30 fps non-drop
• 29.97 ND for 29.97 fps non-drop
• 29.97 DF for 29.97 fps drop frame

So which frame rate should you use?

Start by asking what the video system is doing. That is usually the anchor.

• If the show is built around 60 fps video, use 30 fps timecode.
• If the show is built around 59.94 fps video, use 29.97 fps timecode.
• If the show is built around 50 fps video, use 25 fps timecode.
• If the show is built around 24 fps camera or cinematic content, use 24 fps timecode, but confirm whether the actual rate is 24.000 or 23.976.

The best rule is simple: choose the timecode frame rate from the base frame rate of the content and video system.

Lighting directors, production managers, and musicians do not need to memorize every historical reason these frame rates exist. They just need to know that the frame rate should match the world the show is living in. If the video wall is living at 60 fps, 30 fps timecode fits. If the broadcast truck is living at 59.94, ask before you assume. The video department will either thank you or at least stop glaring, which is basically the same thing.

A real-world concert example

Imagine a pop show with playback, lighting, video, lasers, and automation.

The playback tech builds a session where each song starts at a different timecode offset:

• 01:00:00:00 Opener
• 01:10:00:00 Song 2
• 01:20:00:00 Song 3
• 01:30:00:00 Ballad
• 01:40:00:00 Dance break
• 02:00:00:00 Encore

The lighting programmer builds cues that follow those timecode positions. The media server has video clips lined up to the same addresses. The laser programmer builds looks that trigger at specific moments. Automation may have scenic moves that follow certain sections.

When the artist starts the opener, playback sends LTC beginning at 01:00:00:00. Every listening system locks to that incoming time. When playback reaches 01:00:42:12, maybe the lighting console fires the first big audience blast. At 01:01:08:00, the video wall hits the chorus animation. At 01:02:30:15, lasers enter the chat.

Everyone is following the same clock. That is the sauce.

Why this matters for rehearsals

Timecode makes rehearsals more efficient because departments can program to known moments instead of guessing.

If the artist says, “Can the big white hit happen on the second chorus instead?” the lighting programmer can find that exact timecode address and move the cue. If the video team updates content, they can check whether it still lines up at the correct time. If playback changes the song arrangement, everyone can see what shifted.

Timecode gives the production a shared language. Instead of saying, “the moment after the little drum fill before the chorus but not the first chorus, the other one,” you can say:

“At 01:02:14:08.”

That is cleaner. That is faster. That is less “wait, which chorus?” energy.

What can go wrong?

LTC is reliable, but it is not immune to production goblins.

Common problems include:

• The LTC audio output is muted
• The wrong channel is patched
• The receiving device is set to the wrong frame rate
• The signal level is too low
• The signal is distorted or clipped
• The code is routed through processing that changes the waveform
• The playback session starts at the wrong offset
• One department is using drop frame while another is using non-drop

The classic symptom is a device that will not lock, locks intermittently, or appears to be chasing the wrong time. When that happens, check the basics first: frame rate, drop vs non-drop, signal path, audio level, and starting offset.

Do not immediately blame the console, the server, Mercury in retrograde, or the intern. Start with the boring stuff. The boring stuff wins.

How to test LTC quickly

A fast LTC test should answer four questions:

• Is timecode coming out?
• Is it reaching the correct device?
• Is the receiving device set to the correct frame rate?
• Does the device lock cleanly and follow the correct time?

Use a known frame rate. Route the LTC to the correct audio input. Keep it isolated from the PA. Confirm the level is healthy but not clipping. Then watch the receiving system and make sure it locks to the incoming address.

If playback starts Song 3 at 01:20:00:00, the lighting console should see 01:20:00:00. If it sees something else, do not keep programming and hope it becomes fine later. Hope is not a sync strategy.

LTC vs MIDI Timecode

You may also hear about MIDI Timecode, usually called MTC. The concept is similar: send time information so another device can follow along.

The difference is the transport. LTC is sent as audio. MTC is sent as MIDI data.

Some devices accept LTC directly. Some only accept MTC. Some systems can convert between them. In live production, this matters because the available inputs on a device may decide how you get timecode into it.

For example, if a lighting console accepts LTC, you can feed it the audio timecode line. If a device only accepts MTC, you may need a converter or interface that turns LTC into MIDI Timecode.

The production manager version

For production managers, the important part is not the waveform. The important part is coordination.

Someone needs to decide:

• What frame rate the show is using
• Whether the show is drop frame or non-drop
• Which system generates the master timecode
• Which departments receive it
• What the song offsets are
• Who owns updates when the setlist or arrangements change

Those decisions should happen early. Once lighting, video, lasers, automation, and playback have all programmed to a timecode map, changing the frame rate or offsets later can create a lot of unnecessary pain.

Basically, timecode planning is pre-production hygiene. Not glamorous. Very powerful.

The musician version

For musicians, LTC is usually tied to playback. If your show runs tracks, clicks, stems, or arrangement cues, the playback system may also be sending LTC to production departments.

That means the arrangement matters. If you add four bars before the chorus, cut a bridge, extend an intro, or decide during rehearsals that the dance break should be “more unhinged,” the timecode timeline may change. Lighting and video may need updates.

This does not mean the show has to be rigid forever. It just means changes need communication. Timecode is extremely good at following a plan. It is less good at reading minds.

The lighting director version

For lighting directors, LTC can be a best friend. It lets the console follow exact musical moments, which is perfect for hits, bumps, strobes, color changes, blackouts, and big transition moments.

But the human operator still matters. Timecode can fire the programmed cue stack, while the LD rides intensity, calls spots, handles audience moments, adapts to the artist, and deals with the beautiful chaos of live performance.

The best timecoded shows still feel live. They are not robotic. They are just tight.

The big takeaway

LTC is a shared clock for production systems. It is sent as an audio signal. It carries hours, minutes, seconds, and frames. It lives on a 24 hour timeline. Productions use offsets to give each song or show section its own clean starting address. The frame rate should usually follow the video system and content pipeline. Drop frame still matters in broadcast, but most concert show-control rigs use non-drop.

In plain English: LTC helps the whole show know where it is.

It is the difference between five departments all trying to count bars in the dark and five departments following the same glowing map. Less guessing. More lock. More “that hit was nasty.”

And when the downbeat lands, the wall explodes, the lights punch, the lasers snap, and everyone on comms goes quiet because it just worked?

That is timecode doing its thing.