I see. The first thing that looks fishy to me in AbletonLink::ImplBase is that it’s making calls to Link’s audio thread methods from a timerCallback. For instance:
double getBarPhase (double quantum) override
{
return link.captureAudioSessionState().phaseAtTime (clock.micros(), quantum);
}
although, from Link.hpp:
/*! @brief Capture the current Link Session State from the audio thread.
* Thread-safe: no
* Realtime-safe: yes
*
* @discussion This method should ONLY be called in the audio thread
* and must not be accessed from any other threads. The returned
* object stores a snapshot of the current Link Session State, so it
* should be captured and used in a local scope. Storing the
* Session State for later use in a different context is not advised
* because it will provide an outdated view.
*/
SessionState captureAudioSessionState() const;
Since the whole class relies on this approach, it feels quite pointless to me to try and fix it (unless someone else can tell me they had good results with this code).
I have tested Ian Caburian’s (@SQUARESEQUENCE ) Juce implementation and found it to work very well in a pure JUCE app. It works by polling the Link API from the audio thread.
In the context of TE, I’m not sure how to do this. My current idea is to create a Tracktion plugin, poll the link session from its audio callback, and adjust the transport from here if needed. Does that sound reasonable to you, or would you recommend another audio thread entry point in the engine that would be better suited?