AudioPlayHead position info not working in AU + Live 9

to reproduce: get latest Juce tip (I did this yesterday), build the plugin demo and make a JuceDemoPlugin AU in Live 9. AudioPlayHead info is no longer correct, as follows:

- pos.isPlaying is always returning FALSE. So (playing) does not show up in the UI when it ought to.

- pos.timeInSeconds is always running, even when the transport is stopped. 

This problem does not show up with Apple Logic. The VST version appears to be OK.

other details: Live 9.0.6 32- and 64-bit / OS X 10.9.5 

Stepping into JuceAU::getCurrentPosition() shows that the AU's mHostCallbackInfo.transportStateProc is NULL.



Sounds like Ableton is just not cooperating.. If it doesn't provide a valid transportStateProc then there's not much the plugin can do about that! Maybe raise it with the folks at Ableton?

It's not pretty, but this might be useful for getting a sane test for playback. 

class PlayStatusFlag {


    PlayStatusFlag() :




    ppqLastPos(0.0) {}

    void update(AudioPlayHead::CurrentPositionInfo & cpi);

    bool isPlaying() { return !stopped; }

    bool isStopped() { return stopped; } 


    bool stopped;

    bool wasPreviouslyStopped;

    bool isPlayingIsValid; // false until we spot the host updating the flag

    double ppqLastPos;


void PlayStatusFlag::update(AudioPlayHead::CurrentPositionInfo &cpi) {

    // Can we use the flag?

    if (isPlayingIsValid) {

        stopped = !cpi.isPlaying;



    // If not, is the flag set and we can trust it in future?

    if (cpi.isPlaying) {

        isPlayingIsValid = true;

        DBG("Using cpi.isPlaying flag which appears to be valid");

        stopped = false;



    // Otherwise, have we not moved?  A sign of stoppage.

    if (ppqLastPos == cpi.ppqPosition) {

        wasPreviouslyStopped = true;

        stopped = true;



    // Otherwise, were we stopped last time and now we've jumped?

    if (wasPreviouslyStopped &&

        ((cpi.ppqPosition < ppqLastPos - 0.5) ||

         (cpi.ppqPosition > ppqLastPos + 0.5))) {

            ppqLastPos = cpi.ppqPosition;

            stopped = true;



    // Otherwise, looks like we are playing.

    ppqLastPos = cpi.ppqPosition;

    wasPreviouslyStopped = false;

    stopped = false;


That makes sense, except that this used to work. The previous version of Aalto works (syncs clock) with the same version of Live just fine. Released in May, it used a then-current Juce. Can you think of any changes made this year that might affect the transportStateProc connection?

[a half-hour passes...] I just checked out Juce 2.1.8 (Nov 2013) and tested the plugin demo. The behavior is different but not in the way I was expecting. The timecode in 2.1.8 is simply reporting zeroes, not going haywire. The transport state is the same as the current version: not working. So the transportStateProc issue was a red herring, and probably Live has never been giving the callback to Juce. I'll have to look to other differences to explain why my host sync stopped working. Sorry for any confusion.





I see what you mean, thanks for sharing.

I fixed a bug a while ago whereby the 'playing' variable could have been an uninitialised value. Perhaps in the past you were getting fake 'true' results because of that?

I've got some test code somewhere which measures discrepencies in the various DAWs providing play position data.  I'll see if I can dig it up (or the results from it) there were some pretty weird issues with time going backwards as well as play flag problems..

A-ha! Exactly. Thanks.

I have some if(playing)... code that was required for Logic to behave rationally. Since your bug fix, (playing) is always false in Live.


I have noticed that Logic will send "backwards" times on occasion, and spit out a seemingly totally random value once in a while on stop / start. I have some sanity check code that's all there because of Logic.


Aha!!  Glad someone else sees this too. geesh.

Not sure if it's helpful, but here I am getting different results from run to run.

One time it is working, the next time it is screwed up.

Fairly often it seems that the AP thread is fine, and the MessageManager thread gets incorrect values.  werid.

No idea what's going on ... still digging .... and will post to ableton too.



Fairly often it seems that the AP thread is fine, and the MessageManager thread gets incorrect values.  werid.

You know that you're only supposed to get that playhead info on the audio thread during the audio callback, right? It's not guaranteed to work at all if you call it from the message thread.

be aware that in the same way this 'looping' bug fix may lead to different behaviour as well :

It seems to me that reaper does not set 'looping' correctly.

edit : that has been fixed in reaper v4.78 - released May 4 2015