Recording Back Into The Session Not On Grid..?

[Jon_Atkinson]

Hey all,

Ever since I've been using PT (20+ years) my workflow has been to print mixes back into the session. This works really well for me as a workflow as it means I always have to do one last realtime listen through as it prints. Plus I always have a record of the different mix versions (on playlists)

I route everything to a MIX AUX, and then route from that AUX to an Audio track.

My 'master' bus processing is done on the AUX track.

I generally don't use Master tracks (except if I need to change gain on a bus)

As I say, this has served me well for years, but recently I've come across a couple of instances where it's not playing nicely for me... and I'm guessing this is a Delay Comp issue.

First problem is if I'm creating loops. The printed loop will quite often be late, which then requires another bit of editing before export... No massive pain, except for when you're making a loop sample pack and you have to do this several hundred times. Then it's a massive pain..!

Second, if I'm doing something to picture, I can't then create a demo Quicktime, as the printed audio won't be in sync with the video track.

Third, if I'm creating stems for library, then the stems aren't quite on the grid.

So, as I say this is presumably a Delay Comp issue.

On occasion I have noticed that some of the MixBus plugins I use will send Delay Comp into the red on both the Mix AUX and the Print Audio track, so that would explain this, but actually I get a bit of delay with no red warnings, and nothing on the Mix AUX track

What are you guys doing to get around this? Do you have a different workflow which I should take a look at?
Or should I look at only using Mix Bus processing which PT can handle without tipping over the maximum allowed? (That seems a shame as I'm actually really happy with what I'm using from a sound point of view)

I do have functioning workarounds for all of this, but it's more time consuming than I'd like.... If there's a better workflow then maybe it's time I switched to that..!

(I am also aware that there were Delay Comp issues in 2023.3 but I've not installed that due to some of the reported MIDI issues... Maybe this is something that's fixed in 2023.6..?)

Thanks in advance!

(I should add, I'm pretty much only working at 48k, and there are no hardware insterts. When I come to print it's always audio only. All VI's get printed)

[Jon_Atkinson]

Ok...

So, just did a bit of testing to see if it's Delay Comp, and I'm not sure that's the issue now.

To test, I took a snare sample, ran it through an AUX and printed back into the session.

When I flip the phase on the printed version and play it alongside the original snare sample (which I have re-routed to the Main outs) then I get full cancellation.

I then tried the same but with a high CPU plugin on the Master Aux (bypassed so I don't get any change in sound, but still create a delay), and I also get a full null.

I then did it, but this time with the high CPU plugin duplicated 5 times (to push Delay Comp into the red) and repeated.... And I still get a null....

So now I'm really confused...!

Must be something else in the sessions that's messing with the timing of the re-printed audio.

I have checked a session which I know was massively misbehaving, and there are no weird bus assignments where it doesn't go to anywhere (as I know that can create problems).... And I deleted all the tracks which weren't used in the session (as I know tracks which have had sidechains sent out, then committed can cause weirdness).....

So strange..! Any helpful tips!?

[Darryl Ramm]

You are absolutely sure you are not putting plugins on master faders? (they won't be compensated)

Some comments from tracking down real latency bugs in Pro Tools...

Is this happening in all sessions? Only one? Try starting with an empty test session.

It seems likely this is plugin related so I'd look very carefully there. That might include the possibility that you have a plugin that is reporting the wrong latency, maybe the wrong latency only at specific sample rates, or different plugin settings (like the amount of lookahead on a limiter), etc.

Do you have any signal routing that might be unintentionally going out and back in through to an interface or driver loopback? There you potentially start getting exposed to known bugs.

Work with a click track or similar so you have easy to see transient leading edges and measure the delay between track in samples. You should be able to measure to +/- 1 sample. Is that always there same error, always some multiple of a number? What does delay comp on vs off give, etc. Knowing exactly how many samples something is out sometimes give a useful clue what is happening... and if you suspect a plugin is in error you can measure it's actual delay and compare that to the delay the plugin is reporting to Pro Tools (show in the mixer window delay compensation panels).

[dominicperry]

It may not be of any help, but there are other people printing back in to the session with delay compensation problems

https://duc.avid.com/showthread.php?t=424078&page=3

https://duc.avid.com/showthread.php?t=423144

This is very much a PT problem - because no one other than PT users get into the habit/workflow of printing back into mixes in real time, because offline bouncing and rendering has been available in other DAWs for so long that only PT users do this.....

Dominic

[priorytools]

Just a thought.
Do you have Quick Punch enabled?


Sent from my iPhone using Tapatalk

[Jon_Atkinson]

Hey Darryl,

Thanks for chiming in... I've seen your posts in quite a few other discussions on Delay Comp, and your insight is very much appreciated!

Originally Posted by Darryl Ramm

You are absolutely sure you are not putting plugins on master faders? (they won't be compensated)

Yes... I don't ever use Master Faders except in rare circumstances, and then never with plugins instantiated.

Originally Posted by Darryl Ramm

It seems likely this is plugin related so I'd look very carefully there. That might include the possibility that you have a plugin that is reporting the wrong latency, maybe the wrong latency only at specific sample rates, or different plugin settings (like the amount of lookahead on a limiter), etc.

Yes, that does seem the most likely cause... I'm going to spend the day doing some more digging on this.

I just finished an album where all the sessions behaved like this (11 tracks), so it's likely a plugin I use all the time (irritatingly..!)

I'll report back on my findings later

[Jon_Atkinson]

And just to confirm....

Printing back into the session isn't the problem... I've 100% confirmed in a new blank session that it behaves exactly as you'd expect.

Glad to know my workflow isn't at fault...!

[Jon_Atkinson]

Originally Posted by priorytools

Just a thought.
Do you have Quick Punch enabled?

Good thought, but no. Just confirmed it's not on.

[dominicperry]

Originally Posted by Jon_Atkinson

And just to confirm....

Printing back into the session isn't the problem... I've 100% confirmed in a new blank session that it behaves exactly as you'd expect.

Glad to know my workflow isn't at fault...!

Good!

[Jon_Atkinson]

Ok.... So, results of some testing...

I started out running tests in one of the session I knew had issues.

The initial delay of the printed track with all routing and plugins as per the album mix was 3012 samples.

I made all the session plugins inactive, and the delay of the printed track was zero.

Re-instantiating plugins one by one showed that I have a few regular-use plugins which have some issues:

XLN Audio RC-20 has a minor problem where it actually generates 13 samples more than it reports... This seems repeatable, but it's not a massive amount. Not ideal, but not the sort of numbers I've been seeing. Even with several instances on different tracks the figure still seemed to be 13 samples.

iZotope Ozone 9, (just running Low End Focus), Zynaptic Intensity and Newfangled Audio Elevate which were all on my Mix Bus seemed to have some issues, so I've done further testing:

The main issue seems to be created by Ozone 9 (I think..!), but only seems to manifest in certain circumstances, when the Delay Comp limit is close. And it seems to throw the delay comp off for plugins instantiated after it.

Creating a completely blank session, and clearing all the IO, and just creating the paths I needed, I did as Darryl suggested and used a click to accurately measure delay.

Ozone seems on its own to be accurately delay compensated, but as soon as there are other CPU intensive plugins on that channel it seems to go a bit haywire, even if the maximum threshold isn't apparently crossed. Which suggests that it's just way off with its reporting?

So.. Anyway... I'm glad to have confirmed to myself that there are no routing problem in my sessions, and that the problems I've seen are caused by funky delay comp reporting.

One thing that I couldn't wrap my head around, is what is actually supposed to happen when the delay compensation threshold is breached.

When NOT using Ozone, I was able (in a simple test session) to get it to print 100% on the grid, even when I deliberately exceeded the delay comp limit by loads.... I got as far as 50000 samples, and although the click was audibly delayed (I heard it come out of the speakers way later than it should have), it still printed in the right place.... This only worked with certain plugins used to create that massive delay though.