AUX Related Delay Comp Weirdness..?

[Jon_Atkinson]

Hey all,

Getting an odd behaviour in PT 2019.6...

I'm running a fairly large mix (though not pushing the CPU too hard at all), and trying to print some stems but seeing some fairly odd behaviour.

I have three stems I'm aiming for, each of which are subgroups of drums (one ethnic, one electronic, one live kit)
I've treated each section as though they were an individual complete mix, so they each have their own FX sends and AUXes... So each subgroup has buses within it.

Each subgroup is sent back through an AUX and then printed back into the session. This is a workflow I've been using for years with zero issues, but this is the first time I've seen this behaviour:

I've been seeing some pretty hideous failings with delay comp, where the stems were playing back miles out of time. I initially thought that it was a plugin on one of the AUX channels which might be mis-reporting delay comp amounts, but actually if I route the AUX direct to my main outs then everything plays in time.
If I create a new bus, and route through that to a new audio track then it's horribly delayed.

I've gone through and made sure (I think) that there are no buses which don't go anywhere (as I know that can play havoc with delay comp) but I think it's not that...

But here's the really weird bit...

On the 'live kit' subgroup, with nothing at all on the master bus, if I disable delay comp then it plays in time, and if I enable it then it's hideously early...!

Any thoughts on what I'm doing wrong, or something else I can check...?

[danyg]

where the stems were playing back miles out of time

did you print them in real time or did you bounce offline? Did you try to "commit" your Drum-Bus Aux?

[Jon_Atkinson]

Originally Posted by danyg

did you print them in real time or did you bounce offline? Did you try to "commit" your Drum-Bus Aux?

This is just listening in real time (didn't even attempt to print as it was so far out)

Actually, Committing is a good workaround (as the output of the bus can stay as Output 1/2)...

Weird that I'm consistently getting the same problem when routing audio back into PT through a bus, but not when it goes out the analog outputs.

[danyg]

This is just listening in real time (didn't even attempt to print as it was so far out)

that's not normal. Is PT showing the little "red" symbol in the transport bar when the Delay-Compensation has a problem?

I guess you have something like a loop routing in your session.

[Jon_Atkinson]

Originally Posted by danyg

I guess you have something like a loop routing in your session.

Yeah... That was my first thought too... I guess I might have an AUX hidden somewhere that's not patched properly.

However, even if I create a new Bus I get this behaviour....

So, for instance the live drums sub group (which within it has a few subs) plays fine when routed to Analog 1/2 physical outs, but when routed to a new bus which is then routed to Analog 1/2 I get it playing early by about 1/16th note.

I guess I could reset the I/O to default for Buses...? And re patch everything...?

[Jon_Atkinson]

Originally Posted by danyg

Is PT showing the little "red" symbol in the transport bar when the Delay-Compensation has a problem?

No, all green...

[biasrocks]

Look for orphaned side chains and aux sends.

Mark

[danyg]

absolutely right, there was a post about this

[LDS]

If delay compensation is working when you route your AUX tracks to the master fader, where are they routed to when delay compensation doesn't work? Whatever those destination channels are, I would try holding command and clicking on the 'cmp' written in the bottom of the delay compensation panel in the mix window so that the font turns blue. In 2019.12 it seems like they have changed it to a right click rather than a command click...

Blue mode will bypass the delay compensation on those selected channels. for me, it has always been a prerequisite to get things to line up if a session layout looks something like SOURCE(S) -> AUX(S) -> STEM(S) -> FULL MIX