ABLLinkSetTempo does nothing

[luismartimor]

I've been implementing Link these days and seems to work perfect except for one thing. ABLLinkSetTempo does absolutely nothing. Here is the code relating to the problem. tempoChange is setted only when the user changes the tempo in my app. Why is this tempo proposal ignored ?

const UInt64 hostTimeAtBufferBegin = inTimeStamp->mHostTime + soundStructPointerArray[0].outputLatency;
    const ABLLinkTimelineRef timeline =
    ABLLinkCaptureAudioTimeline(soundStructPointerArray[0].ablLink);
    if (soundStructPointerArray[0].tempoChange) {
        ABLLinkSetTempo(timeline, soundStructPointerArray[0].tempoChange, hostTimeAtBufferBegin);
        soundStructPointerArray[0].tempoChange=0;
    }

[brs-ableton]

Hi @mekeo,

Just so it's clear, you're using the LinkKit 2.0.0-Beta-1 release, which is a pre-release (not ready for production yet). I expect that we'll have a production-ready 2.0.0 release relatively soon, so if you can wait a little bit it makes sense to build on this but I just wanted to make sure you're aware.

As to your question, I think the problem is that you're not committing the modified timeline after you change it. ABLLinkSetTempo modifies the timeline that you pass to it, but the Link session does not change until you actually commit a modified timeline using ABLLinkCommitAudioTimeline. You can call the commit function unconditionally at the end of your audio callback because if the timeline hasn't changed it will be a no-op.

We've made the API more transactional in this 2.0 version for a couple of reasons:

• For a given buffer, a client gets a consistent view of the link state by capturing a timeline and then operating on it locally. If every call to query the beat time or quantum results in grabbing the latest state of the library, it's possible that the client will get inconsistent data between the beginning and end of the buffer because the state could be changed in the middle of a buffer due to session activity.
• Client code must synchronize with the Link state at most twice during a buffer (once to capture, once to commit) instead of once for every function call. This reduces thread contention on the Link state and improves performance.
• It allows a client to make prospective changes, analyze the results, and then throw them away without committing them if desired.

[luismartimor]

Perfect answer, thanks!