Pro Tools Studio Hardware Inserts...

[BScout]

Originally Posted by Dax Productions

to actually have your compensation be sample accurate, wouldn't we have to input the delay amount in samples? A more precise measurement than milliseconds.

I have asked for this lots and Avid have suggested this would be coming. But the reason to do it in samples is to make the setting adjust auto/correctly if you have different sample rate sessions.

The current millisecond numbers (which goes to 1/100th of a millisecond) will get you close enough to sample accuracy at many sample rates (1 sample at 48kHz is 0.0208333 ms and actual output won't be subsample but rounded to closest so the error in math isn't necessarily a sample error in round-trip) Put another way, the millisecond number is the actual approximation and it is actually on a sample. So testing the roundtrip after entering the delay, you can check if it is aligned to the sample. If not, you adjust the insert delay by 1/100th of a millisecond (plus or minus 1) so the "rounding error" is in you favour to make it sample accurate.
All that is in the math. When doing results-based measurements (looping a sine wave blip and measuring the diff between original and recorded), you get the right delay number every time when measuring. No math needed.

[Dax Productions]

Originally Posted by BScout

I have asked for this lots and Avid have suggested this would be coming. But the reason to do it in samples is to make the setting adjust auto/correctly if you have different sample rate sessions.

The current millisecond numbers (which goes to 1/100th of a millisecond) will get you close enough to sample accuracy at many sample rates (1 sample at 48kHz is 0.0208333 ms and actual output won't be subsample but rounded to closest so the error in math isn't necessarily a sample error in round-trip) Put another way, the millisecond number is the actual approximation and it is actually on a sample. So testing the roundtrip after entering the delay, you can check if it is aligned to the sample. If not, you adjust the insert delay by 1/100th of a millisecond (plus or minus 1) so the "rounding error" is in you favour to make it sample accurate.
All that is in the math. When doing results-based measurements (looping a sine wave blip and measuring the diff between original and recorded), you get the right delay number every time when measuring. No math needed.

Appreciate the explanation. It does make sense. It still doesn't even come close to working properly for me though. I'm not sure if you read my situation, but I'd have to be able to enter a negative value in the insert delay window, which you can't do.

I see you're on an HDX system. Maybe it works as advertised on HDX. Whenever I'm on an HDX rig I'm doing all my back bussing on a console so latency doesn't even enter into it. Maybe next time I'll take some time to do an experiment so I can see how its supposed to work!

[Chevron]

Originally Posted by Dax Productions

Appreciate the explanation. It does make sense. It still doesn't even come close to working properly for me though. I'm not sure if you read my situation, but I'd have to be able to enter a negative value in the insert delay window, which you can't do.

I see you're on an HDX system. Maybe it works as advertised on HDX. Whenever I'm on an HDX rig I'm doing all my back bussing on a console so latency doesn't even enter into it. Maybe next time I'll take some time to do an experiment so I can see how its supposed to work!

One important thing to bear in mind, is that you can not add a negative delay in the HW Insert Delay settings.

So if Pro Tools has a round trip figure for your non Avid hardware of let's say 0.13 ms or 6 samples at 44.1 Khz, and in reality it is less than this by 1 sample or more. You can not compensate for this with a negative HW Delay Insert setting

In this situation, it is better to leave the HW Insert Delay at 0 and manually compensate on the track User Offset Field by + 1 sample or to match the differential. 



I find using Waves InPhase, if you have it to hand, is really handy to work out the exact delay and better than recording to a new track for me, especially as it is a moving target in Pro Tools and changes often. Why it moves I don't know as the audio driver I assume reports the same delay, even if nothing changes with plugin instances or routing changes can happen - been discussed for years with us 3rd party interface folks. Fortunately once you have it compensated manually on the track it doesn't change often enough to drive you totally crazy.....

[K Roche]

Originally Posted by Darryl Ramm

What is the exact question here?

The "delay compensation" feature is about software inserts/plugins compensation.

Hardware inserts are not included in the "delay compensation" feature you set the latency manually for hardware inserts, in Setup>IO>Insert and have been able to do so for ages. Pro Tools has no way of knowing what some external hardware latency is. So measure it and insert the value there and you are usually done.

Darryl does the "HW inserts not included" only apply to 3rd party interfaces and not apply to Avid interfaces ?

Specifically with My Carbon interface, when I have my HW comp and reverb inserted on their own Aux Input tracks. And I have Auto Delay Compensation turned on for the session, I do get an ADC reading in those Aux tracks ????So I assumed I did not have to do a manual compensation ...............

[BScout]

Originally Posted by K Roche

Darryl does the "HW inserts not included" only apply to 3rd party interfaces and not apply to Avid interfaces ?

Specifically with My Carbon interface, when I have my HW comp and reverb inserted on their own Aux Input tracks. And I have Auto Delay Compensation turned on for the session, I do get an ADC reading in those Aux tracks ????So I assumed I did not have to do a manual compensation

Even for Avid hardware it is manual.

Auto Delay Comp is for mixer routing/plugins. The ADC you are seeing is for the buffers necessary for the Carbon to operate. But that does not guarantee that the hardware loop for an insert is compensated. (it could, it could not match up)

[Darryl Ramm]

I'd be happy reading BScout's replies all day (I'm distracted trying to understand another problem I ran into so may not reply here in a while).

Folks we keep saying it. "Delay Compensation" and hardware insert latency are different things and not related.

I wish Avid had named "Delay Compensation" "Plugin Delay Compensation" or "Plugin Time Shover", something, anything, ... but make it not seem like a omnipotent latency fixeroo thingy that will fix any latency a user can think of.

Please please play with stuff, get a trivial one track session, **turn off** Delay Compensation since it's for plugins, and play with hardware inserts, and setting up the latency adjustment as described in the reference guide.

Yes it bloody well should be configurable in samples. And as other users have pointed out in the past other DAWS provide more automated hardware insert latency (aka ping) measurements. It might be nice for Avid to do this as well, but this is not top of my list of issues in this area, it would be good for Avid to address user confusion over this, I'd support a ping utility if it was part of an overall way of doing that (but you still need manual adjustment).

[K Roche]

Originally Posted by BScout

Even for Avid hardware it is manual.

Auto Delay Comp is for mixer routing/plugins. The ADC you are seeing is for the buffers necessary for the Carbon to operate. But that does not guarantee that the hardware loop for an insert is compensated. (it could, it could not match up)

Just wanted to say thanks for your reply It was very helpful
I had for all these years just assumed the ADC was working for my HW inserts
For one I did not understand it was compensating just the system and plugins
and I never really heard anything sounding like latency or delay

So I ran the test as per the PT Reference Guide and and discovered that there was no delay for my Tube Core Compressor But my Bricasti M7 had some tiny delay of 1 MS But being a reverb is I suppose why I never really noticed it
But in any case it is now corrected . Thanks again, Kev