Automation line is later than faded move? Why

[kinghand]

Protools Ultimate 2022. 10, same module version S4.

When I pull off the fader on beat 2, the recorded automation line drop on beat 3 or whatever. And the sound fades on beat 3 too. When I playback, the fader moves earlier than the automation line and sound.

Anyone who also experienced the same?

Any way to fix this?

通过我的 Mi 10 Pro 上的 Tapatalk发言

[kinghand]

I measured the latency, it's around 300ms.

通过我的 Mi 10 Pro 上的 Tapatalk发言

[kinghand]

I found out where the problem comes from.
If an audio track goes to a folder track or bus Then go to another bus. When I automate the audio track, the automation line delays.

If the audio track go to one bus only and then directly to speaker. No delay occurs.

Is there any way to fix it?

[creativecontrol]

Under Setup > Session > System Delay > what value are you seeing in this session currently?


Jeff

[kinghand]

Originally Posted by creativecontrol

Under Setup > Session > System Delay > what value are you seeing in this session currently?


Jeff

Thanks for your reply.

The system delay is 33021 samples due to my complex routing and huge latency plugins. But the auto delay compensation still green. So is this the reason why? Is there any way that I can solve this?

Thanks!

[kinghand]

I've tried to simplify the routing and reduce the system delay to around 11000 samples. but the problem remains. Isn't there any compensation method for the controller like S4?

[smurfyou]

Are you using Penteo upmix? Just curious. It has a "Low latency" option that improves it. Other high latency plugins might have similar options. Might still be tough to go right on a beat though...

[Farhoof]

This is simply the way delay works.

You have a track with audio and a fader. You play the track. The audio goes trough a lot of plugins delay before it reaches the output and your speakers and eventually your ears. You respond by pulling down the fader on the track at the beginning of the chain, but the playhead of the track is already passed the point you are responding to.

Delay compensation works by calculating the delay of your tracks and all your complex routing and such, and actually playing back the track earlier than the playhead. This aligns all track in a way so all tracks reach the speakers at the same time as intended. But the delay between the track and the output will always remain. Protools can not know ahead of time what your fader movement will be.

Maybe it is technically possible for Protools to shift the fader automation backwards by the amount of delay on that track chain (only after the write pass), but then your second playback will be different from what you just heard and mixed. That might be fine in this case, but in other cases not.

You can partly solve this by moving insert with lots of delay towards the tracks, as the track fader is after the inserts so this delay is not added to the chain. The more plugin delays between tracks and output the more fader lag you will have.

[smurfyou]

^ Good advice.

I'll add that if I was trying to automate to the beat I might even temporarily do what Farhoof advises - duplicate the track and route in a way that doesn't go through the delayed path. If you have a lot going on in your processing this won't make sense but could be worth a shot. Then when you're happy just copy the volume auto down to your real track.

[kinghand]

Originally Posted by Farhoof

This is simply the way delay works.

You have a track with audio and a fader. You play the track. The audio goes trough a lot of plugins delay before it reaches the output and your speakers and eventually your ears. You respond by pulling down the fader on the track at the beginning of the chain, but the playhead of the track is already passed the point you are responding to.

Delay compensation works by calculating the delay of your tracks and all your complex routing and such, and actually playing back the track earlier than the playhead. This aligns all track in a way so all tracks reach the speakers at the same time as intended. But the delay between the track and the output will always remain. Protools can not know ahead of time what your fader movement will be.

Maybe it is technically possible for Protools to shift the fader automation backwards by the amount of delay on that track chain (only after the write pass), but then your second playback will be different from what you just heard and mixed. That might be fine in this case, but in other cases not.

You can partly solve this by moving insert with lots of delay towards the tracks, as the track fader is after the inserts so this delay is not added to the chain. The more plugin delays between tracks and output the more fader lag you will have.

Thanks for your explanation. I've found that the latency is caused by the plugins on buses. Which means if there is latency on audio track, the faders are behind plugins, so the latency won't affect them. But the buses are behind faders, so their latency do affect the audio track faders.

But the strangest part is, based on this, the waveform display should be earlier than the sound I hear but it's not.