Problem with ProTools ppqPosition

General JUCE discussion
1

Hi,
We are having a problem with ProTools on both Win and Mac. When we call AudioPlayHead::getCurrentPosition from within ProcessBlock(), the ppqPosition is incorrect. It appears to be lower than it should. Eg. If we start playback at position 0, it returns a negative value. It seems to return the incorrect value when playing (ie. not when stopped).

Just wanted to see if any others had seen this issue. We are only experiencing it on ProTools. All other DAW’s return the correct position.

Thanks.

2

Something quick to check - it isn’t just that pre roll is turned on inside Pro Tools and so playback is starting earlier than you’re asking it to?

3

Doug,
No, pre-roll is not turned on in this case.

1 Like
4

Have you checked the return value isn’t offset by your buffer size?

Rail

5

I don’t think so… My buffer size is 1024. I trace into the getCurrentPosition function in juce_aax_wrapper.cpp when it starts playing at position 0.

transport.GetCurrentNativeSampleLocation() returns -440 for samples, and transport.GetCurrentTickPosition returns -19156.
My sample rate is 44.1k and am at 120bpm in this case.
Any other ideas?

6

might be helpful to provide a code snippet on your processBlock, sometimes there’s a tiny thing :slight_smile:

What AAX SDK version are you using?

7

Hi,
I’m using version 2.2.2 of the AAX SDK.
I just created a brand new plugin to make sure it is not an issue in my code. I simply added the following to the pre-generated code in ProcessBlock:

AudioPlayHead *ph = getPlayHead();
AudioPlayHead::CurrentPositionInfo posinfo; 
ph->getCurrentPosition(posinfo);
if (posinfo.isPlaying) {
   dummy=posinfo.ppqPosition;
}

And set a breakpoint on the “dummy” line. If I start at position 0.0.0 in ProTools this ends up as a negative value. If I start on eg 5.0.0 (ie 16 beats in), the value here is less than 16 (15.997732291666667 to be precise).

Thanks.

8

In Pro Tools… in the Audio prefs… try turning off the option to ignore errors and see if that makes a difference – that option can mess with ADC && timing in PT

Rail

9

Hi,
I tried this. It was actually off and I turned it on, I also tried combinations of it with and without the “minimize additional i/o latency” as well as dynamic plug-in processing, but doesn’t seem to make a difference.

Another thing I noticed in playing around with it is that if I just keep starting and stopping playback and break on that getCurrentPosition() line, I don’t always get the same value for ppqPosition (even though I’m always starting at 0.0.0. For example, I got these values when doing it a few times: -0.015, -0.045, -0.014, -0.004

Any more ideas?

10

We are having a similar problem - try changing from "GetCurrentTickPosition” to “GetCustomTickPosition” in the AAX wrapper and see if that fixes it. For us that worked.

11

I might add that this only worked when delay was introduced by plugins on other channels in pro tools so this might be a completely different thing.

12

Thanks, I will give it a try

13

I just tested my plug-in a few days ago with the tip and my Bars/Beats display matches the Pro Tools Bars/Beats counter. I checked both MacOS and Windows with the latest PT build and 2p2p2.

Rail

1 Like