Delay Compensation in RED?

[WildHoney]

So, I've got Delay Compensation enabled. On a number of tracks, the dly info is in red, which normally would lead me to believe I've exceeded the "short" delay comp setting and need to go to the "long" setting, but in this case none of the tracks in red are delayed more than 150 samples or so, and nowhere in the track (red or green) is there more than about 200 samples worth of compensation. I tried, just for kicks, to go to the "long" setting, but no change. Anybody know what this is about and how to remedy?

[thin ice]

I get this with Altiverb RTAS version. Reports 800, but applies no compensation. However, it only goes red on some sessions.

[WildHoney]

Might be the same issue, although all the plug-ins used on these tracks are TDM. Even still, if the delay on your altiverb is 800 samples, even the short delay compensation setting should be enough to compensate it -- shouldn't be displayed in red. I've scoured the manual on this, but found nothing but the standard stuff about delay compensation.

[jre3132]

from the reference guide:

• 
  When the total delay on a track exceeds the
  amount of compensation available, Pro Tools
  applies the maximum available compensation,
  and displays the delay information in red (in the
  Delay Compensation View) for any tracks that
  cannot be fully compensated. The Delay Com-
  pensation indicator in the Edit window also
  turns red to indicate that the track delay exceeds
  the Delay Compensation limit. In this case, you
  need to bypass the track’s reported delay (see
  “Plug-in Delay (dly) Indicator” on page 554),
  then manually nudge the track to maintain
  proper Delay Compensation (see “User Offset
  (+/–) Field” on page 554).
  

[WildHoney]

from the reference guide:

• 
  When the total delay on a track exceeds the
  amount of compensation available, Pro Tools
  applies the maximum available compensation,
  and displays the delay information in red (in the
  Delay Compensation View) for any tracks that
  cannot be fully compensated. The Delay Com-
  pensation indicator in the Edit window also
  turns red to indicate that the track delay exceeds
  the Delay Compensation limit. In this case, you
  need to bypass the track’s reported delay (see
  “Plug-in Delay (dly) Indicator” on page 554),
  then manually nudge the track to maintain
  proper Delay Compensation (see “User Offset
  (+/–) Field” on page 554).
  

Yup, that's what I found in the manual as well, but that doesn't describe this behavior. The numeric readouts clearly show that there's not more than 100-200 samples of delay -- so there's plenty of delay compensation "headroom." Yet, the numbers still display in red as though the tracks had exceeded the amount of available delay compensation. What's described in the manual is what you'd expect if you put a plug-in with 3000 samples of delay on a track when your session is only set to "short" delay compensation (1023 samples of compensation). But that's not what's happening here.

[Stig Eliassen]

Have you tried to de-activate plug-ins? Like a search'n'destroy kinda thing?

[Andre Knecht]

Personally, I would follow Stig-R’s recommendation above.

Next, I would quit PT, trash DAE preferences and restart.

There is one aspect to all this which hasn’t been addressed by WildHoney, namely the mixer structure used in his session. The compensation required in a session is cumulative for a track’s entire path. In other words, while it may be true that individual tracks do not exceed 200 samples (as per original post), if tracks get routed through a series of Aux and Master Fader channels introducing delays, then those need to be added. Obviously, the system is in charge of such additions, but it pays to be mindful of it.

Does the session feature a complex routing scheme?

Also, and in conjunction with the above paragraph, are there any hidden (but active) tracks featuring hi-latency plug-ins, in the session?

If disabling plug-ins one at a time, and none of the above helped point to a solution, allow for the fact that this specific session is corrupted. Create a new session and import your tracks and media from the troubled one.

IHTH.

[drenkrom]

Would it be that Pro Tools applies the delay compensation up to the limit of your setting and displays REMAINING samples in red? So if you're set for 1023 samples of compensation and you see a red 200, your plugin actually generates a delay of 1223 samples. That would explain it, especially since I doubt Altiverb produces only 800 samples of delay. if I remember well, that's one hungry plugin.

Isn't it time Digi caught up with the competing DAWs that have been doing seemless automatic plugin delay compensation for at least 5 years? That is one thing on which Pro Tools is waaaaay behing the competition.

[JSR]

I believe (but may be wrong) that the tracks that show the least amount of delay compensation are actually the track that are causing the most delay. The way that delay compensation works is the tracks that have the least amount of needed delay compensation are actually delayed the most so they'll in up with tracks that are incurring a lot (or more) delay. So when the delay comp lights in the red it is saying "this track is causing the delay comp to go over".

[WildHoney]

Personally, I would follow Stig-R’s recommendation above.

Aha, I did as Stig suggested and found the culprit. . . L3 on the sole master fader in the session. When the L3 is deactivated, delay comp appears as normal. Now, I use an L3 on the master fader on virtually every session, so still not sure why in this case it's causing a problem.

Next, I would quit PT, trash DAE preferences and restart.

Did it. . . several times. . . doesn't change anything in this particular case

There is one aspect to all this which hasn’t been addressed by WildHoney, namely the mixer structure used in his session. The compensation required in a session is cumulative for a track’s entire path. In other words, while it may be true that individual tracks do not exceed 200 samples (as per original post), if tracks get routed through a series of Aux and Master Fader channels introducing delays, then those need to be added. Obviously, the system is in charge of such additions, but it pays to be mindful of it.

Does the session feature a complex routing scheme?

Well, I don't know if i'd call it a "complex" routing scheme, but there are probably about 7-8 stereo auxes running, some of which are running aux-> aux (i.e. Lead Vox bussed to aux 1-2, BV's bussed to aux 3-4, BOTH of those bussed to an All Vox aux 5-6 which is then bussed to analog via the master fader), a couple of auxes with verb on them, a couple with delays, a couple with H300's. . . .

So, I've found the culprit in the L3, but still not sure what else is leading to this point, since I use a similar routing scheme and master fader on many, many session without this delay comp weirdness.