Locking up for video gigs

[Beech]

Hi folks,

We started to discuss Sync I/O dropout issues during long video shoots so I thought it might be an idea to start a new thread. First off let me say that for better or worse I am compelled to record live shows to Pro Tools with Radar backup on important shows. Last year I managed to have both sets of recorders drop out... Pro Tools just briefly but it still took me a 1min 30 before it decided that it was happy to jump back into record. The PTools was beside the stage and the Radars were in the TV truck. I cannot say what happened to the Radars but it stinks of human error.

So the first thing I've learned is to make sure that I know exactly where the TC and video sync are coming from. Even so, there are a couple of choices in the session setup and I'd like to get some feedback on the pros and cons of each.

1. Freewheel. Ok, so this is fairly self explanatory. The setting goes from 0 - 120 frames. Does this come into play when there is a problem with both TC and sync or just TC?

2. Jam sync. I don't know too much about this. Does it only come into play if it spots a problem? Or is it running in Jam for the duration of the lockup...

I presume once Jam is used the drift occurs and gets progressively worse as the show goes on.

Any thoughts on this?

[mspence@mac.com]

The PTools was beside the stage and the Radars were in the TV truck. I cannot say what happened to the Radars but it stinks of human error.

If both machines in two different locations had problems simultaneously, then it's something gone awry in the truck, I would think.

So the first thing I've learned is to make sure that I know exactly where the TC and video sync are coming from.

Absolutely!

1. Freewheel. Ok, so this is fairly self explanatory. The setting goes from 0 - 120 frames. Does this come into play when there is a problem with both TC and sync or just TC?

Well, now you made me break out the manuals. And the manual gives no info whatsoever. So I locked the PT rig to a video source in my home theatre system through the video reference in on the Sync I/O. Not using any TC. It ran fine until I pulled the coax, at which point I got an error message. However, the machine stayed in record and kept going. I let it run without video reference for a few minutes, and then plugged the coax back in. I got another message telling me that PT was now locked. In Freewheel/None mode, the TC on the counter on my screen was 4 minutes ahead of the TC on the front of the Sync I/O, which is the amount of time it didn't have clean video reference In Jam mode, the TC counter on the Sync I/O matched the screen once sync returned. The Sync I/O quit generating TC on the TC out connector when it lost sync. So don't slave your Radars, or HD backup of choice, off of the Sync I/O TC output. Get a DA and split the feed from the truck to both recording systems independently. And leave them in jam.

2. Jam sync. I don't know too much about this. Does it only come into play if it spots a problem? Or is it running in Jam for the duration of the lockup...

The manual is no help here, either. Neither is Wikipedia. My transfer of ownership through Digi isn't official yet, so I can't get any tech support. I did find this quote on-line:

"By using jam syncing, the slave device can be instructed to ignore small dropouts of time code from the master, thus ensuring smooth synchronization. To do this, it generates its own time code whenever the master's time code is missing."

OK, 'whenever' TC is missing. Hmmmm.... That could mean it is just filling in it's own TC whenever the master is missing. But, if there is an interruption, and the machines drift a bit while the slave waits for stable TC, and then tries to lock up when stable but not matched code returns, wouldn't that generate yet another error? Based on that, I would assume (there's that word again) that once TC is interrupted, the slave stays on its own until you stop the machine, regardless of whether or not clean code is again available.

I presume once Jam is used the drift occurs and gets progressively worse as the show goes on.

That's what I had always believed. Although not optimal, it's simply not an option to have our machines park while in record, because 'somebody tripped on a cable', or, as in your case, the truck had a brain fart of some sort. If we're only running 20 minutes at a time, I can live with that, as long as they were locked at the top of the take. Not ideal, by any means. However, for a 2 1/2 hour live show, things could get pretty dicey in post. I've had directors tell me that they don't even use the TC most of the time, and just line stuff up in the timeline. Hopefully the error occurs towards the end of the show, so at least we had frame lock for most of it, or at least some of it. Regardless, I'm probably going to become increasingly adamant about just how the truck is deriving the TC/sync it is sending to me. Preferably directly off a spigot on their generator, straight to me. If it's a long run, it needs to go through a DA or buffer whilst on it's way to me. And I will still always run in jam. If our record lights aren't on, we're pretty useless. Also, this isn't just a Pro Tools thing. Whether it's DA-98's, two inch, hard drives, or VTR's, once a machine is unlocked, it's unlocked, and it's going to drift. May the system with the best clock win. :-) As PT users, it just looks like jam is our only option to stay in record. Or bring our own generator and make everyone lock to us. I like that option the best.


Any thoughts on this?

I'd like to hear some, too. I probably just got everything completely wrong. Anyone?

[Beech]

If both machines in two different locations had problems simultaneously, then it's something gone awry in the truck, I would think

.

No, actually both recorders did not dropout simultaneously. Not that it matters now, I've moved on from that situation and am just thinking about future shows.

Micheal

Thanks for trying the experiment with the video ref but I'm not sure that it tells us much unless you also had timecode connected.

Unless someone who knows about this stuff can help out here I think maybe the best way to see what happens is by doing a test of our own. How about this:

Borrow or rent a pro video machine and get a tape with about two hours of audio on it. It must also have TC.

Connect TC and Video Ref to Pro Tools record the video tape's audio.

Wind the video tape back and slap Pro Tools into record again, this time recording the video tape's audio onto a second pair of tracks.

Start by altering the TC level to the Sync I/O while in record in Freewheel. Find the optimum TC level that the Sync I/O likes. Make a note of the minimum and maximum.

Wind the tape back again and set the Pro Tools to Jam sync. Screw around the the TC level again and see what happens. Presumably the recorder will stay in record... but how great is the drift.

I know I should add more to this but I've run out of time for now. The bottom line is if we are going to use Pro Tools for live recordings, since it was not really designed for that purpose, we may have to find out for ourselves what it's tolerences are.

Over to you!

PS: Could someone please define exactly what Jam Sync means.

[Remoteness]

A timecode refresher or reshaper can be used to reduce the amount of TC errors. But, if a portion of the TC is missing the slave device will stop unless you provided jam sync.

As we may already know, with a basic SMPTE timecode set up, TC is fed from the master to the slave. The slave device chases the time code points as communicated by the master device. If the master TC has an error caused by a dropout or some other reason, the slave would not know what to do for that moment in time since it lost its directive from the master. Jam sync is a SMPTE timecode option you can use when you need the slave device to furnish its own timing while the time that a master device is momentarily unstable. When using jam sync, the slave would be directed to ignore any small dropouts of TC from the master. This keeps the TC synchronization running efficiently.

Remember, in jam sync mode the device generates its own timecode whenever the master's TC drops out. Jam sync takes over generating code when the source code stops. Keep in mind when in jam sync, it’s ‘freewheeling’ totally independent of the original TC so, it works best when there are short or small dropouts.

[Beech]

Remember, in jam sync mode the device generates its own timecode whenever the master's TC drops out. Jam sync takes over generating code when the source code stops.

Thanks for that Steve.

A few questions:

What happens to the slave when the master TC corrects itself? How does the slave 'catch up?

What is the difference between Jam sync and Freewheel?

[Remoteness]

The slave machine freewheels until the master is back.

I'm not completely sure with regard to the PT HD but, my guess is that in freewheel mode it's completely on it's own where in jam sync mode the slave machine only freewheels when the host (master) machine lost timecode.

Open letter to all timecode gods in practice -- Please correct me if I'm wrong.