Manual Delay Comp Problem

[WinTaper]

Sorry, but this answer is wrong. Frankly, I expected more from digi.

How many times do we need to say - we are talking about INPUTS not INSERTS? Or have you found some way to record thru inserts?

also, the buffer setting selections on my RME are in samples not milliseconds. Besides the fact that the HW Insert Comp rounds millisecs to 2 decimal points - introducing rounding errors.

Sonar, Cubase, Nuendo all get this right. PT9 does not. Like it or not - its a bug - or at best a missing capability.

I was looking forward to using PT but if this problem isn't corrected, the product is useless.

And the level of denial around here is ridiculous.

[WinTaper]

vans316:

you have hit the nail on the head with what this topic is about.

unfortunately, everyone keeps thinking the problem is insert compensation.

The answer to your question, at the moment, is *no*, there is no way to have PT shift the overdub to align with the previous track.

Despite the fact that other DAWs handle this correctly, so far all I've heard is "there is no bug" and then we're directed to the hw inserts page of the manual.

[25ghosts]

Originally Posted by DigiTechSupt

You use the H/W Insert Delay offset, as indicated by Albee. This info starts on page 962 of the Pro Tools 9.0 Reference Guide.

No, it's not sample-rate dependent. The hardware has a fixed latency in milliseconds. If you change the sample rate, you'll just see the number of samples of delay change, however the overall time in ms will not change.

Example - 72 samples at 44.1k is 1.633ms (rounded to the 3rd significant digit). If you were to measure that in a 88.2 k session, the number of samples would change to 144, but the time in ms would remain the same.

DTS,

OP was refer. to Recording Overdubs. NOT INSERTS...

OP's topic IS very viable and SHOULD be fixed for third PTY interfaces.

Why dont you just add a feature like the HW Delay so that a usr can manually enter a WISHED for value that EVERY overdub should be advanced in time....

This feature would be great for the many HD users using Apoge interfaces etc...

And quite frankly, I dont see how this could be a huge issue. Especially since most other DAWs are already featuring this.

[DigiTechSupt]

Originally Posted by WinTaper

Sorry, but this answer is wrong. Frankly, I expected more from digi.

How many times do we need to say - we are talking about INPUTS not INSERTS? Or have you found some way to record thru inserts?

also, the buffer setting selections on my RME are in samples not milliseconds. Besides the fact that the HW Insert Comp rounds millisecs to 2 decimal points - introducing rounding errors.

Sonar, Cubase, Nuendo all get this right. PT9 does not. Like it or not - its a bug - or at best a missing capability.

I was looking forward to using PT but if this problem isn't corrected, the product is useless.

And the level of denial around here is ridiculous.

I should have been more explicit and I also referenced the wrong person.

You don't have to say anything more than once - I get it. Sometimes, though, given the hundreds of DUC posts I'm not able to give every one of them the amount of attention it needs. The comments about someone being surprised that no one from Avid has chimed in is one of the reasons I wanted to at least put something in this thread, though I think, in hindsight, that it was premature.


SteveBoker had it right regarding the H/W Insert Delay in this post:

http://duc.avid.com/showpost.php?p=1711016&postcount=30

Now, unless I'm mistaken, that should work for you. Yes, I know you're NOT using inserts, but we're just doing this as a workaround. I should have been more clear on that.

And, yes, the ability to manually compensate for delays has not been fully implemented yet, for various reasons.

One thing I wanted to point out is that delays in interfaces should automatically be compensated for via the ASIO or Core Audio polling that occurs at driver level and the only manual compensation that should be needed is when you have an external device in your recording chain that's inducing additional delays.

I did want to point something out, though - you say:

also, the buffer setting selections on my RME are in samples not milliseconds.

The RME is your interface you're using for Pro Tools, correct? If so, it should automatically be compensated for as long as it's reporting it's correct delays via the ASIO or Core Audio driver. The only delay you should have to compensate for is for the device(s) between the microphone and the RME. Is that what you're doing? The buffer in the RME, if it's the primary Pro Tools interface, is automatically compensated for.

[DigiTechSupt]

Originally Posted by 25ghosts

DTS,

OP was refer. to Recording Overdubs. NOT INSERTS...

OP's topic IS very viable and SHOULD be fixed for third PTY interfaces.

Why dont you just add a feature like the HW Delay so that a usr can manually enter a WISHED for value that EVERY overdub should be advanced in time....

This feature would be great for the many HD users using Apoge interfaces etc...

And quite frankly, I dont see how this could be a huge issue. Especially since most other DAWs are already featuring this.

Just to clarify - all devices that use ASIO or Core Audio driver should automatically report their delay via the driver to Pro Tool, which then compensates for that.

The only delays that should need to be compensated for are ones that have no way of reporting to Pro Tools directly - hardware inserts or devices in the recording chain. Most analog devices have zero delay and most external digital hardware devices have delays in the order of a few samples.

We are aware of the usability problem that is caused by not having user-definable record delay compensation and will look at ways to possibly improve this in the future.

HD/TDM with interfaces other than Digidesign/Avid is a slightly different story, since there's no 'open' protocol for devices to be able to report their delays, which is why all the compensation doesn't work properly with Apogee, Lynx, etc.

[WinTaper]

Sorry if I was a bit gruff, DTS.

Yes, I'm using an RME HDSP 9652. And it reports latency and PT compensates for it correctly. If I loop the ADAT optic out to an ADAT input (no DA-AD) everything is perfect.

The problem is, I have a Focusrite Pre-amps with internal A/D cards and they are connected to the RME via optic (ADAT) lines. The RME has no way of knowing the latency of the Focusrite pre-amps (ie their A/D converter buffers) so it only reports its own latency. But I can measure it using the loopback technique. That measurement is in samples - the size of the buffer causing the latency. It stays the same regardless of sample rate because it is a fixed-size hardware buffer.

To be honest, there is also playback latency in my system, and from measuring the (DA->AD) ping loop we cannot tell if the buffers causing delay are in the 'out' or 'in' stage - but since we're interested in the *overall* roundtrip (reported latency + unreported) it doesn't matter.

What we care about is being able to time align an overdub sample accurate. I'm not asking for PT to automagically figure out this value. I'm saying we need the ability to (optionally) enter some value in samples to represent this non-reported buffer. We figure out this value doing the loopback ping test through our DA-AD loop and measuring. Others who have done this are getting the same results as myself.

Since I'm a computer programmer with some experience in digital audio, I'm guessing digi interfaces have similar 'hidden' buffers. In the case of the M and LE gear, my assumption is the drivers are accounting for the AD and DA latencies because its all "in the same box". In the case of HD systems, I would imagine this information is carried along the midi data between HD cards and front ends like the PRE.

The simplest solution is an edit box on the I/O settings input tab allowing the entry (in samples) of additional latency during record. Any recorded tracks would be bumped ahead by that value (actually, drop the fist X samples).

For extra credit, PT could disable this transparently when no tracks are playing back (straight record vs overdubbing) since alignment wouldn;t be necessary in this scenario.

If you really wanted to nail the feature, an input similar to the HW Insert dialog (but in samples) would be really nice. That would allow you to set record latency on an input-by-input basis. Which would be really cool and very pro-tools-like

-Dan

[WinTaper]

BTW - is any way to rename this thread "Recording Delay Comp Problem" ?

[upscaps]

Originally Posted by DigiTechSupt

We are aware of the usability problem that is caused by not having user-definable record delay compensation and will look at ways to possibly improve this in the future.

great to hear

[25ghosts]

Originally Posted by DigiTechSupt

HD/TDM with interfaces other than Digidesign/Avid is a slightly different story, since there's no 'open' protocol for devices to be able to report their delays, which is why all the compensation doesn't work properly with Apogee, Lynx, etc.

Hi DTS,

why not just have a field in which one could enter the delay he wishes for. A la the HW Delay page in the I/O Setup.

That way the apogees would not need no protocol etc. The user could just enter any given MS value which the regions would be advanced by !

[vans316]

I'm glad someone has understood what it is I'm talking about, (WinTaper, Recording overdub delay problem), I thought I was going mad with thinking about different scenarios that didn't exist! The fact is, that 70 samples or 1.6 ms is so small a delay that it doesnt really make a difference in the real world, but considering the investment leap from a 003 set up to HD, to get zero latency, then people will spend thousands to correct a small delay such as this. Having said that, even if I had HD, I would still have the same amount of control room to live room delay so either way, without sorting out a manual recording delay offset in samples there is no need for me to upgrade to HD for this purpose. What would be the point..... Samples would still be late on input.

By the way, I tested a staight audio loop from my outputs to inputs on the 003. Audio track out playing a click, to recored audio track in. No plug ins any where. Recorded audio landed 1 sample after the origional track. Is this correct. Or should it land spot on? Sorry if I'm taking this to the extreme!! Anyone else done this test?