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.
Thanks Rail, I'll continue testing with PT11 and let you know if we find anything.
Is there an AAX plug-in that does this correctly so that I have a good comparison of which accuracy is achievable?
Automation in Pro Tools 11 is time stamped and should be sample accurate. Test using one of the included plugs.
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.
well this is not very satisfying, it means that currently all juce based aax-plugins not working right at the moment :-/
@fabian, maybe there is a much simpler solution, please have a look
Is this issue now resolved in JUCE 4?
Sorry we haven’t had time to implement this yet.
Bumping this, I have a plugin that has quite a bit of latency and the automation seems to fire early by that amount of latency. Weird!
Also curious if this was ever resolved.