Re: Delay compensation ignored on commit?
 

total delay value on the source track?

Re: Delay compensation ignored on commit?
 

the total delay(compensated) on the original track was about 3500 (orange color)

Re: Delay compensation ignored on commit?
 

ok, there may be a particular plug-in we need to look at. I would systematically make inactive one plug-in at a time and attempt commit and see if you can identify what is pushing it out of sync. are you seeing sync issues with any other tracks? Also do an online commit and an offline commit and see if there are any differences. Once you know which plug-in may be impacting it, the data point of online vs offline commit may be helpful to know

Re: Delay compensation ignored on commit?
 

ok I keep on studing. The dly value is exactly 3545. I think I had a bigger offset around 6 ms with Waves DeBreath, which is causing dly over 35000 (red color)

Re: Delay compensation ignored on commit?
 

Just thinking outloud here...

We all know that delay comp has limitations when playing in real time, hence the red indicator when the delay becomes greater than what PT can compensate for, but "commit" isn't harnessed by real time hardware/software/CPU attributes so why shouldn't it be able to align itself appropriately with the rest of the track when converting to audio, regardless of the delays?

Re: Delay compensation ignored on commit?
 

Good question Eric.

I'm also curious as to why there's a limitation in this regard.

Re: Delay compensation ignored on commit?
 

Yes and no to Eric's statement. If you unselect offline in the dialog window, then you should be able to commit with outboard inserted on tracks with proper delay compensation applied to the new tracks. Same with offline for plugins. Otherwise it defeats the purpose and would be unfortunate..

No more quick punch routing trickery to print external outboard..

Re: Delay compensation ignored on commit?
 

Pro Tools "commit" should match what the mixer can do in real time. It doesn't make sense for Commit to do something you can't do in real time. It would be confusing because of its inconsistency.

Re: Delay compensation ignored on commit?
 

I strongly disagree and can't find any single reason why the two need to match. There should be an evolution of this technology, not an adherence to an unnecessary and antiquated limitation. What would be the practical point of that? When we make the decision to commit a track we've left real-time audio for good reason and we want audio in sync.

In fact, "commit" could become a NEW option for situations when a track is forced to cross the compensation threshold. I'd even argue that it makes zero sense to limit this function artificially IF ProTools is able to compensate for any delay when freezing tracks.

Out of curiosity, how does Logic deal with this?

Re: Delay compensation ignored on commit?
 

The hardware limitation I was referring to was CPU horsepower, which plays a role in the buffer settings we're able to select. Outboard gear is another issue, but shouldn't hinder delay compensation when bouncing offline.