Time Lag when Printing Tracks

[Cayce]

I have a session with a lot of tracks that I need to print down to one and export periodically into another session. I bring the printed track into the partner session through the "Import Session Data," so it's a session-to-session direct import. My imports were arriving off-meter, though the session Im importing into is an exact copy the original in its meter and setup. I went back into the original session where I'm printing the track, included the click track and discovered it's printing off-meter, lagging by about 50ms, enough to be a problem. Thinking it might be a delay compensation issue, I engaged that, and the result was that it was now printing ahead of the mark by about 200ms.

I created a new session with three tracks: a click track, and two tracks to print the click track, one with compensation, the other without. Both tracks recorded the click track dead on the mark, so the issue is in the original working session. Is it typical when printing a complex session that it will delay somewhat, or is there a problem with the session, maybe a setting I'm not aware of?

The attached image will show the click track being printed in the original session, showing the lagged and advanced printing with compensation on and off. It also shows a double click on the first click in the track where it lags, another odd behavior that may be a clue.

Any help would be appreciated.

Thanks.

[Darryl Ramm]

And how *exactly* are you printing these tracks?

Why were you operating without ADC anyhow? Was there other ADC issues?

Are you using hardware inserts?

What playback engine are you using (especially wanting to know that is not an aggregate).

Can you report latencies issues in samples (and sample rate).

If you are printing by actually playing out of a physical output and recording that then no plugins on the maser fader are ever ADC compensated.

If using Bounce, what *exact* source(s) are you bouncing?

Bounce should correct for plugin latency, including on on master faders (unlike what you get with actual live outputs).

It's easy when say bouncing a mix with a combination of physical and other outputs to see problems with latencies on the different tracks get offset as ADC tries to correct for the physical output latency... which for example can push back in time other bounced tracks if they are not physical outputs (To me that's yet another Pro Tools latency/ADC bug and ADC should be capable of handling each bounced track correctly).

And even though Pro Tools should handle this normally, you can try things like removing (not bypassing) plugins on the physical output master faders and see if that makes a difference here.

[Cayce]

Hey, Darryl;

"And how *exactly* are you printing these tracks?"
I have an input bus on the receiving track, routing my sub-mix to that same bus. Arm the receiving track to record and go.

"Why were you operating without ADC anyhow? Was there other ADC issues?"
I pretty much keep ADC in play. Was toggling it on and off to diagnose.

"Are you using hardware inserts?"
Nope.

"What playback engine are you using (especially wanting to know that is not an aggregate)."
It is, indeed, an aggregate. I have two DSPs coming in: a PreSonus 32R and a UAD Apollo x8p.

"Can you report latencies issues in samples (and sample rate)."
Not up on how to do that.

"If you are printing by actually playing out of a physical output and recording that then no plugins on the maser fader are ever ADC compensated."
Not doing that.

"If using Bounce, what *exact* source(s) are you bouncing?"
Not bouncing in this case... just internal printing. But when I do bounce, I go straight out of my Main output.

"Bounce should correct for plugin latency, including on on master faders (unlike what you get with actual live outputs)."
I first tried bouncing then importing the bounced file, but PT randomly adds time at the beginning of the bounced file so that it doesn't align at 1|1|000 when imported, causing similar problems. I contacted PT Support over that, but they're pretty much useless.

"It's easy when say bouncing a mix with a combination of physical and other outputs to see problems with latencies on the different tracks get offset as ADC tries to correct for the physical output latency... which for example can push back in time other bounced tracks if they are not physical outputs (To me that's yet another Pro Tools latency/ADC bug and ADC should be capable of handling each bounced track correctly)."
I don't utilize any physical or other outputs. Everything I do is pretty much in the box, bouncing for wav files, etc. It's a fairly simple, straight forward arrangement.

"And even though Pro Tools should handle this normally, you can try things like removing (not bypassing) plugins on the physical output master faders and see if that makes a difference here."
It's doing this even when I go straight from my Click track into the Print track, via a bus, where there are no plugins involved.

I was hoping to find out I accidentally effected a setting somewhere that could be corrected, but have a feeling my metering on the session has been corrupted. There was a point when I needed to add four measures to the beginning of this very complex piece (well over a hundred tracks), a hair-raising experience I'll de everything to avoid from here onward.

Thanks for your help on this, Darryl.

[Darryl Ramm]

Originally Posted by Cayce

"What playback engine are you using (especially wanting to know that is not an aggregate)."
It is, indeed, an aggregate. I have two DSPs coming in: a PreSonus 32R and a UAD Apollo x8p.

OK, that's very unlikely to be related since you are not going out an actual output, but just in case there is a bug here it might be good to test with one of the interfaces by themselves, not in an aggregate.

"Can you report latencies issues in samples (and sample rate)."
Not up on how to do that.

Put your main time display in sample mode. When you then click on an event in on track with the edit cursor and drag along to another event in a different track the "Length" display then measures how many samples are between those events. Knowing the number of samples or latency sometimes helps guess the cause of a problem.

I was hoping to find out I accidentally effected a setting somewhere that could be corrected, but have a feeling my metering on the session has been corrupted. There was a point when I needed to add four measures to the beginning of this very complex piece (well over a hundred tracks), a hair-raising experience I'll de everything to avoid from here onward.

Nope nothing in Pro Tools that I can think of that you have left off.

A very simple session like your test session in printing back to another track like this, with no plugins at all should not be needing any ADC so the fact that the recorded track offset differs with ADC on or off is suspicious.

Are you seeing any ADC latency numbers reported on each track? What are they (in samples).

Are there any hidden tracks (actually check).

Are there any live physical inputs or any way stuff is getting to a physical outputs? I'm just fishing for stuff that might somehow trip up ADC issues/bugs. Is the bus you are printing through mapped to an output? Use a non-mapped bus, yes the Output I/O selector will prevent you confusing mapped bus outputs (aka interface outputs) and non mapped busses (aka busses) but I've seen situations where outputs get names like "bus ..." and people miss they are mapped to an output when looking at stuff. You can also just uncheck all "Mapped to Output" in IO Setup > Bus. Again stuff like that should be OK in normal use, I'm just looking to strip away any actual outputs or inputs in case it's possibly causing ADC bugs.

Is there anyway that the signal you are are recording is going though the UAD Console? i.e. DAW returns to the Apollo console and back into a Pro Tools track. Just make double sure, including look at the UAD Console meters while doing that recording and make sure they are not moving.

If you can reproduce this on a simple test session can you share the session somewhere.

[Cayce]

Hey, Darryl...

I'm not done with this, didn't want you to think I'm not appreciating your focused help, but have a deadline breathing down my neck forcing me to work around it for now. I'll be back on it, having a smaller issue in the meantime.

Thanks.

[BScout]

Turn off auto-low latency (blue mode) on your end (print) track (and any other preceding submix tracks (for instance if you print stems and also bus the stems to a full mix during the same print, you'll want auto-low latency turned off on all those tracks being put into record.)

To do this, go to the end/print track, right click in the delay comp area on the Mix window and you'll get the option to turn auto low latency off. If you do it right, the delay comp numbers will turn blue to tell you it is off.