Negative tick values - RTAS wrapper

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);

    Cmn_Float64 bpm = 120.0;
    Cmn_Int32 num = 4, denom = 4;
    Cmn_Int64 ticks = 0;
    Cmn_Bool isPlaying = false;

    if (midiTransport != 0)
        midiTransport->GetCurrentTempo (&bpm);
        midiTransport->IsTransportPlaying (&isPlaying);
        midiTransport->GetCurrentMeter (&num, &denom);
        midiTransport->GetCurrentTickPosition (&ticks);

Any thoughts?


Hi Steve,

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?


PreRoll imho.
This happens in older host so external device get in sync in time.

For anyone who’s interested, it looks like it’s simply a bug in Pro Tools that’s responsible for this behaviour:

Hopefully that solves your problem!


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…