a few milliseconds?

williemyers · Post by **williemyers** » Mon Sep 17, 2012 7:37 am

I know it's just a few milliseconds, but I noticed something today and would appreciate input?
I was bouncing an audio track to another audio track. The first one has a distinct "pop" at the head (the ol' "2pop)). On the resultant bounce (imported in to the session), that pop occurs about 800 samples later than in the original - at 44.1k, about 18 ms. Just wondering if this sounds about right and what factors/settings, if any, might effect this latency?

zaratero · Post by **zaratero** » Mon Sep 17, 2012 1:45 pm

Check 3d party plugs first.

Dan Worley · Post by **Dan Worley** » Mon Sep 17, 2012 2:10 pm

It should be exact. There should be no shift. What plug-ins (if any) do you have inserted on the source track? There are several ways to route for this, and all routes should work perfectly, but how do you have things routed?

Prime Mover · Post by **Prime Mover** » Mon Sep 17, 2012 2:20 pm

Actually, I believe that if you have any "look ahead" dynamics plugins like MW Limiter or Gate (as well as most other mastering plugins), it adds a delay to the entire sequence. At least that's the case with Waves L3, and I can't imagine it working any other way, since it must account for incoming audio (which you couldn't look ahead of without having a time machine). Not sure how these things effect bounce-downs though.

Tritonemusic · Post by **Tritonemusic** » Mon Sep 17, 2012 2:48 pm

Prime Mover wrote:Actually, I believe that if you have any "look ahead" dynamics plugins like MW Limiter or Gate (as well as most other mastering plugins), it adds a delay to the entire sequence.

As far as MW Limiter and MW Gate are concerned, that is not correct. The Lookahead setting will not create a delay in the bounce if using those two plug-ins.

Dan Worley · Post by **Dan Worley** » Mon Sep 17, 2012 4:41 pm

Even routing like this should not cause time shift in a real-time bounce:

Source Track send: Bus 1-2
Aux Track input: Bus 1-2 (Plug-ins: Waves H-EQ, Waves L3 MultiMaximizer)
Aux Track output: Bus 3-4
Audio Track input: Bus 3-4

Results:

And now adding two more plug-ins to the chain, Slate Mastering Comp and MW Limiter (lookahead 20ms):

williemyers · Post by **williemyers** » Tue Sep 18, 2012 3:40 am

hey guys, *sincere* thanks for all of the replies! yesterday, I actually wrote a reply, but - for some obscure reason - it didn't make it in to the thread. perhaps I just hit "preview" when i thought I'd hit "submit".

anyway, back to the topic. the short answer is.... no plugs at all! and no bussing or Auxes. just going from one Audio track, digitally to another.

Actually, if I wrote that it was a "bounce", that wasn't correct. What it was, was taking an audio track ("A") and routing it (digitally OUT/digitally IN) to another track ("B"), then hitting record on "B" and letting it roll. And the resultant soundbite in "B" has the 18ms delay.
So that was it, and again, many thanks for the responses...

daniel.sneed · Post by **daniel.sneed** » Tue Sep 18, 2012 6:51 am

BTW, ADC stands for Automatic Delay Compensation. That is DP taking processing time in count and keeping everything tight.

But some third party plugins don't publish their delay times in a proper manner, or at all, and DP can't align audio.

In my setup, only one does not publish right, or at all. It's ADT. A free doubling fx. And that is 30 ms late in DP!

Dan Worley · Post by **Dan Worley** » Tue Sep 18, 2012 7:20 am

williemyers wrote:Actually, if I wrote that it was a "bounce", that wasn't correct. What it was, was taking an audio track ("A") and routing it (digitally OUT/digitally IN) to another track ("B"), then hitting record on "B" and letting it roll. And the resultant soundbite in "B" has the 18ms delay.

Yeah, that's a real-time bounce and there should be no time shift whatsoever just like the examples above (and below) show--even though the routing in the above examples are more involved, I was just making a point.

You are routing through internal buses right? I mean you're not routing out to your interface and then back in are you?

Results:

Kubi · Post by **Kubi** » Tue Sep 18, 2012 10:59 am

If you're routing out and back into the computer, you'll likely get delay - not sure if you'll get delay when using the digital out and in, but I never tried that. Silly question - why rout out and back in? If you use busses there will be no delay at all, and unless you are doing external processing, there's no reason to use anything other than busses.

If you're routing outside to do some external digital processing it makes sense to use the digital out/digital in, and depending on the external digital processing, you'll likely get more delay. Either way, DP can't make up for any external delay automatically, since you're leaving the computer and it has no way of knowing what the delay will be.

If this is a setup you commonly use, measure the roundtrip delay once (as exact as you can) by recording a pop out and back in using this exact setup and measuring the resulting delay to the sample. Then input the result into a plug-in called "Latency Fixer" by expert sleepers. Instantiate that plug-in with that value on the source track every time you use this setup, and DP will compensate for the roundtrip delay from here on out.

williemyers · Post by **williemyers** » Tue Sep 18, 2012 11:28 am

Dan Worley wrote:You are routing through internal buses right? I mean you're not routing out to your interface and then back in are you?

Kubi wrote:If you're routing out and back into the computer, you'll likely get delay - not sure if you'll get delay when using the digital out and in, but I never tried that. Silly question - why rout out and back in? If you use busses there will be no delay at all, and unless you are doing external processing, there's no reason to use anything other than busses.

oooopps.....

you guys didn't happen to catch my quote at the bottom of my sig., did you? "...I never wanted to be a recording engineer - and I'm not..."!!
yes, I have been routing out to my interface (Digi002R), then back in to DP, i.e. track "A" output = "DIG L-R", track "B" input = "dig L-R". In making the recording pass on "B", I would have "A" play and a VI (output "DIG L-R"), as well. Both going to "B"'s input. The result was a mix in "B" of "A" and the VI. Everything *sounds* great, it's just that 18ms time shift that caught my attention.
I'm going to try the same process today, using "bus 1-2" and see what happens, will let you all know!
again, many thanks

williemyers · Post by **williemyers** » Tue Sep 18, 2012 12:03 pm

bingo!
when done using buss 1-2 (OUT of "A" & IN to "B") - and zoomed down to the sample level - no delay...at all!
I guess, all these years, I've been delivering my clients tracks that were 18ms delayed. Perhaps that's been their justification for making my checks 18 weeks delayed!!!

Dan Worley · Post by **Dan Worley** » Tue Sep 18, 2012 12:05 pm

williemyers wrote:bingo!
when done using buss 1-2 (OUT of "A" & IN to "B") - and zoomed down to the sample level - no delay...at all!
I guess, all these years, I've been delivering my clients tracks that were 18ms delayed. Perhaps that's been their justification for making my checks 18 weeks delayed!!!

Great! Now you'll get payed on time!

williemyers · Post by **williemyers** » Tue Sep 18, 2012 12:14 pm

Dan Worley wrote:Great! Now you'll get payed on time!

wishful thinkin', but thanks for the thought!! (and for your all's explanations!)

Dan Worley · Post by **Dan Worley** » Tue Sep 18, 2012 1:50 pm

Dan Worley wrote:
Great! Now you'll get payed on time!

Payed?

Oh my, I need some sleep or some new brain cells.

MOTUnation.com

a few milliseconds?

a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?

Re: a few milliseconds?