PT 6.9.2cs2 Inconsistent LTC Chase

[snoopy]

Thanks for the details, Snoopy.

Switching from 512 to 256 shouldn't make a difference anyway - I only asked because twice in the last couple of months, some problems were traced to customers using a VERY high h/w buffer size.

A few questions - some of them are routine, but they have to be asked...<g>.

Are you using QuickTime in your session, and if so, does the behavior change when the movie is off-line?

Are you recording to PT when this problem occurs, or is it occuring when you change from recording to playback or vice-versa?

If you are recording, are you using QuickPunch or TrackPunch, "recording at selection" or "recording at TC lock?"

How many tracks are you recording/playing back?

Min sync delay setting? All other settings default?

When you describe the Nanosync as being "house sync," do you mean the Nanosync is providing black burst to the Sync I/O, or is it providing WC into the SYNC I/O?

Is the Sync I/O the "loop sync master?"

Do you recall problems when you were using OS X 10.3.8? (had to ask, since we don't support 10.3.9 with Pro Tools|HD).

You mention your LTC hookup - confirming that you are not using Remote Mode, and also when you say "vice versa," what *exactly* do you mean? Are you checking and unchecking the "generate TC" box in order to drive the SSL with PT-generated time code?

Now that we have the gear config, it's really important that you describe your workflow to a "T" to make sure we haven't missed anything. If you can give us a step-by-step for your master/slave operations, that would help.

Thanks!


Danny Caccavo
Digidesign

Thanks again for responding. I am off for a couple days, and some of the questions will take waiting for the problem to occur to answer since I don't recall from the past (didnt pay enough attention). For now, let me answer what I can.

1* No quicktime involved.
2* No recording during the problem per say. But I do eventually record into PT, so often a track may be armed or in input. I can't verify if this has been the case during the long lockup times. I will have to take notes next ocurance.
3* Sometimes quickpunch is used, sometimes not. Not sure if it's always the same mode during the problem. I will check next few occurances and take notes. Pretty much use "record at TC lock".
4* Track count can be anywhere from 30-150 tracks. It seems to happen regardless of the track count as far as I can tell. I will have to pay more attentiona s to it maybe happening more often on larger track counts.
5* I have not set the sync delay, soI will have to check and report back. I believe when I first notced the problem a while back, someone suggested an alternat setting. I tried it, made no difference, so I switched back to defalt. Again, I will need to check to confirm that.
6* The Nonasync provides blackburst to the equipment in the room, and WC to SYNC I/O.
7* The SYNC I/O is indeed the loop master.
8* The problem did occur in 10.3.8. I reluctantly went to 10.3.9 because a client insisted on using Soundtrack, which required it, and I thought it could possibly help. I will be switching to Tiger next week as I don't like using anything unsupported, even if it seems to work fine.
9* The LTC mode. Remote mode is used, but we switch back and forth. LTC is fed both to and from PT and the console. When switching, "generate sync" is switched on in PT and serial control is armed on the console. This way the console transport can be used when convenient for listening purposes, and the PT transport can be used for functionalty purposes (printing, quickly jumping to sections, recording stems that only play in a few places, etc). And obviously the lock up problem only occurs when PT is acting as the LTC slave.

Some other notes are that we record off an internal IDE drive, not firewire. Not the same dfrive as the OS, but a dedicated internal audio drive. Don't trust firewire very much yet, and feel it's safer to use the intrnal drive. Perhaps this might be an issue? I can imagine on high track count sessions, working off one drive is not up to spec (or supported), but it does occur on low track counts as well.

Also, have been seeing the max record time to 20 minutes (dunnno if it has any bearing).

[snoopy]

Thanks again for responding. I am off for a couple days, and some of the questions will take waiting for the problem to occur to answer since I don't recall from the past (didnt pay enough attention). For now, let me answer what I can.

1* No quicktime involved.
2* No recording during the problem per say. But I do eventually record into PT, so often a track may be armed or in input. I can't verify if this has been the case during the long lockup times. I will have to take notes next ocurance.
3* Sometimes quickpunch is used, sometimes not. Not sure if it's always the same mode during the problem. I will check next few occurances and take notes. Pretty much use "record at TC lock".
4* Track count can be anywhere from 30-150 tracks. It seems to happen regardless of the track count as far as I can tell. I will have to pay more attentiona s to it maybe happening more often on larger track counts.
5* I have not set the sync delay, soI will have to check and report back. I believe when I first notced the problem a while back, someone suggested an alternat setting. I tried it, made no difference, so I switched back to defalt. Again, I will need to check to confirm that.
6* The Nonasync provides blackburst to the equipment in the room, and WC to SYNC I/O.
7* The SYNC I/O is indeed the loop master.
8* The problem did occur in 10.3.8. I reluctantly went to 10.3.9 because a client insisted on using Soundtrack, which required it, and I thought it could possibly help. I will be switching to Tiger next week as I don't like using anything unsupported, even if it seems to work fine.
9* The LTC mode. Remote mode is used, but we switch back and forth. LTC is fed both to and from PT and the console. When switching, "generate sync" is switched on in PT and serial control is armed on the console. This way the console transport can be used when convenient for listening purposes, and the PT transport can be used for functionalty purposes (printing, quickly jumping to sections, recording stems that only play in a few places, etc). And obviously the lock up problem only occurs when PT is acting as the LTC slave.

Some other notes are that we record off an internal IDE drive, not firewire. Not the same dfrive as the OS, but a dedicated internal audio drive. Don't trust firewire very much yet, and feel it's safer to use the intrnal drive. Perhaps this might be an issue? I can imagine on high track count sessions, working off one drive is not up to spec (or supported), but it does occur on low track counts as well.

Also, have been seeing the max record time to 20 minutes (dunnno if it has any bearing).

Again, thanks for your time! I will fill in the missing info in a couple days.

[Tim Fletcher]

Hi there,

Just to chip in with my 2 pence, I'm also having this problem. I've got two identical HD2 systems with 64 Digi I/O + Sync I/O. We chase these to timecode generated from our consoles. As stated by others in this thread, it takes 2-10 seconds to lock up and sometimes not at all. By the time it's locked the bit you wanted to listen to is way gone. It has a bad lockup about every 10 times. I've tried 6.9, 6.9cs1 and 6.9.1 all on a dual 2GHz running 10.3.8 all exhibiting the same problems. I would go back to 6.7 where this definitely did not happen but then I would be faced with the non srolling in timecode chase bug! I potentially have to go back to 6.4cs9 if that will give me the stability we require. I hope Digi manage to recreate this.

[DigiTechSupt]

As Danny mentions, we're not seeing this in house, but we certainly would like to get to the bottom of it. There's obviously more required to reproduce this problem than simply locking to LTC, so the more details you can provide, the better.

Tim - could you describe your setup in more detail (Danny's questions above are a good place to start)? What sample rate?

Snoopy - Looking forward to hearing more details from your end. To confirm that the problem isn't track count related, can you confirm that it occurs with just 10 mono tracks? What sample rate are you working at?

BTW, I have to ask...has everyone trashed all preferences?

-Jordan

[BW DoggyDawg]

Jordan,

i´m seeing that problem even in a Ultra Mini Sessions containing a Mono and a Stereo Audio Track.

(i already gave Danny infos on bbs)

It´s not a matter of track count, and its good to see that NTSC ppl see that problem too.

Yesterday i had a nightmare session with Clients beside me (10.38 PT 6.9.1cs1).

When PT was controlling the Video machines PT started hopping for half a minute and didn´t lock at all.

After that, I switched PT in remote mode and used the machine control of the Avant.

BW

[HDUser13]

I have had the same problem many times when locking pro tools to the SSL J9k.
Basic setup, using SSL transport to transmit 30ND LTC directly into the Sync I/O.
Lock time can randomly vary from 3 to 10 seconds, and sometimes not at all.
Does this with all software versions on the 9k, but seemingly random making it very difficult to reproduce intentionally.
Our tech's are completely stumped as to what the cause is.

[snoopy]

I have had the same problem many times when locking pro tools to the SSL J9k.
Basic setup, using SSL transport to transmit 30ND LTC directly into the Sync I/O.
Lock time can randomly vary from 3 to 10 seconds, and sometimes not at all.
Does this with all software versions on the 9k, but seemingly random making it very difficult to reproduce intentionally.
Our tech's are completely stumped as to what the cause is.

The only thing that puzzles me here is that the J9k can't put out 30ND LTC. Well, unless you are clocking off pulse or something (hence the option in the settings). But otherwise it only outputs 29.97 which will cause the automation to drift over time if PT is set to 30. The reason being that the SSL only sees video for sync.

As for the question earlier about sample rate, 99% of the time it's 44.1k. I'm on a little vacation right now, but maybe I can jump in this weekend and try out a 10 track session.

Thanks to everyone who is contributing to this thread!

[HDUser13]

If im not mistaken the timecode runs from our 9k into a conditioner unit that converts it to 30ND, and distributes it to PT, and all the studio panels. Regardless, we also are experiencing the long lock time bug on occasion. I'm just confirming that the problem does indeed exist, and rears it's ugly head at seemingly the most innoportune moments possible.
You tech types kill me...

[DigiTechSupt]

Okay, I've received confirmation from a few of you that this occurs at 48k and that MachineControl is not required (chasing LTC only). Also, it can occur with just playback (recording not required).

Could everyone try setting Delay Before Locking to LTC/Time Code in Preferences>MachineControl to 10 frames and post your results? The location of this pref is a bit misleading as it isn't specific to MachineControl. It applies anytime Pro Tools is receiving incoming code.

Also, please post which scroll option you're using (in Operations>Scroll Options). And, do you have Auto Save enabled in Preferences>Operation?

Thanks,
Jordan

[snoopy]

OK, I jumped in the studio and am doing some testing as I type. I have formatted the drive, installed OS X 10.4.2 and PT 6.9.3cs1. I have made no changes yet to any preferences, they are all system defaults, except auto-backup (which I am suspecting) is set once a minute. Also, Open ended record allocation is set to 20 minutes. Chasing LTC from the SSL, I getlock times between 1 second and 16 seconds. Mostly 1-4 seconds and the occasional 16 second lockup time (maybe once every 10 tries or so). This is with a track count of 32 (16 st tracks) at 44.1k using both external WC, and internal (tried both ways). Playing back from internal SATA drive (not system drive). Also, using stereo mixer, no surround involved. No serial involved, just locking off 29.97 LTC from an SSL J9000. No pre roll, nor count in. Sync delay is 40. Nothing is input, nor are any tracks armed. teh SYNC I/O is loop master. TC reader offset set to 0 samples. Sync firmware 1.1.1. 24bit BWF audio files.

Drive info: 232.76GB, Journaled HFS+, no OS9 drivers. . Not sure of the model/speed.

Reducing track count to 10 tracks (5 stereo): Same results

Turning off Auto-Save: Same results

Turned on SYNC setup (was off be default): Same results.

Set Sync delay to 100: Seemed to work better until I hit a record of 25 seconds.
Set Sync delay to 30: Same results.
Set timecode reader offset to 50: No lock.
Set freewheel from 8 frames to OFF: Same results

Session has some Plugins causing delay off 7117 samples (51 smpls). Removing them: Same results

Set positional reference from LTC to Auto LTC: Same results.

Ran disk warrior 3.03 on the audio drive: Same results.

I've run out of ideas and time for the night, but hopefully this info will help a little bit.