We are developing a new AAX plug-in and have encountered an issue in Pro Tools 11. The automation data is being sent to the plug-in approximately 60ms too early.
If we manually draw in some mutes around, for example, a snare hit, we need to deliberately place the cut 60ms after the snare transient for it to be accurate. This does *not* happen in Pro Tools 10.
I have tested the Pro Tools 12 beta and the same problem exists.
The plug-in has a latency of zero as it's doing very little in the way of audio processing, so I doubt there's a problem with delay compensation.
Does anyone have any ideas? We have tried everything we can think of!
I haven’t tested for automation accuracy recently… but in PT10 automation was never sample accurate and probably won’t be consistent, in PT11 and later it should be. I would test with PT 11 release in case the 12 beta has a bug.
We're still struggling to find a working solution for this here. If something can be done at the Juce end to solve it, that would be great. We've tried a few different schemes but so far have not found one that gives us accurate automation without a performance hit in the plug-in.Â
The problem we have observed is that PT11/12 can call UpdateParameterNormalizedValue in the AAX wrapper upto 3 buffers early, so data arrives around 60ms ahead at the plug-in setParameter. Previously we hadn't seen this behaviour with Pro Tools, or other hosts, and we have a AAX plug-in that is fine with PT10 with an accuracy within one buffer.
Looking at some of the examples in the PT SDK there are a variety of methods used to update parameters, most of them use GenCoefficients to create a timestamp and PostPacket to add the data to the queue. The algorithm then ensures that the data arrives at the plug-in at the correct time.
we have put this issue on our road-map along with properly supporting sample accurate parameter changes for various plug-in formats. This will be available in the next release of JUCE.Â
