Automation offset bug

[Sonopolis]

So I just had an error with plug-in automation confirmed as reproducible by Avid CS and thought I'd let you know as it is potentially dangerous.

I had several instances when plug-ins changed their status too early. Most obvious when the automation was written to the end of a clip this is resulting in unwanted noises.

Basically the same as described in this post:http://duc.avid.com/showthread.php?t=413227
however not on Atmos tracks but on regular audio tracks. If the audio is re-recorded you can clearly see the automation change reflected in the waveform, in the screenshot below it's only the compressor's gain. This happens with several plug-ins , like fabFilter Q3, Waves Q10, Renaissance Compressor and others. It is probably related to plug-in delay compensation. Changing the algorithm on Q3 largely affects amount of the automation being too early.

This is on Majave with PT2020.12 Ultimate.

Bildschirmfoto 2021-01-12 um 01.50.43.jpg

Bildschirmfoto 2021-01-12 um 02.03.49.jpg

[Farhoof]

Good to know, thanks. Is this also present in earlier versions of PT?

Does this also happen when you do an offline bounce?

I'm keeping track of (serious) bugs these days to mark which PT versions to avoid...

[Sonopolis]

Yes, same thing with offline bounce. However I don't know in which version this bug was introduced. I remember that there was an update addressing specifically this a long time ago.

[bolooki]

when you freeze an affected track- does the frozen waveform show this bug as well? or is this only when recording routed audio or bouncing audio thru a master bus?

[Sonopolis]

Yes, same result. What's interesting here is that the frozen region is also a bit too long.
Bildschirmfoto 2021-01-13 um 04.25.19.jpg
This is with iZotope Neutron EQ btw.

Can't you replicate this? CS could quite easily.

[bolooki]

I was dealing with this using midi triggering as well. The midi note would arrive and trigger early unless I disabled delay comp on that one track before freezing.

Any chance the delay amount corresponds to the track delay or overall session delay? Wonder if we can atleast offset automation by a specific # depending on the track delay.

Personally with the midi trigger example I had, it wouldn’t correspond exactly to the track delay but the amount it was off by was repeatable on each freeze. So atleast that was consistent. (For ref it was LFO tool on an aux receiving a midi note from a separate midi track)