I’m trying to figure out why the RTAS wrapper would be getting negative tick values from Pro Tools.
I’m calling getCurrentPosition (AudioPlayHead::CurrentPositionInfo& info), which calls midiTransport->GetCurrentTickPosition (&ticks). First time through after playback begins I get ticks = -22291 (which converts to about -11ms) even though the track is positioned at 0 seconds in PT. After a couple buffers of audio, the value starts heading up to positive territory. Also, if I select a later section of the track, the start times come out offset by around the same amount (-11 to 12ms).
Here is the Juce wrapper code I have:
bool getCurrentPosition (AudioPlayHead::CurrentPositionInfo& info)
{
// this method can only be called while the plugin is running
jassert (prepared);
This is pure guesswork but is it offset by the Pro Tools playback buffer size? i.e. the value set in Setup/Playback Engine/HW Buffer Size. When you hit play in Pro Tools the insertion point always jumps back by this amount before it starts playing. 11ms sounds like about 512 samples at 44.1kHz maybe? Try changing the buffer size and see if that affects your offset value. If it does I’d say the values you’re getting probably correspond to exactly what Pro Tools is doing.
By the way, I’m not entirely sure why Pro Tools does this and I’ve never really tried to find out. Does anyone happen to know?
Yes, the H/W buffer size does affect the amount pre-roll, although I have pre/post-roll off with their values set to 0. The size of the pre-roll I get seems to be twice the size of the H/W buffer for some reason.
Not sure what my plug-in should do about this - I guess ignore buffers until the time is >= 0.
[quote]Not sure what my plug-in should do about this - I guess ignore buffers until the time is >= 0. /quote]
I guess it depends on your application. Why not just process them anyway? Unless you’re doing some processing that’s tied to the tick values in some way…