Feedback loop with tempo propose

[sinosoidal]

Hi,

I'm having a problem. I have implemented Link as in Link Hut, with the LinkData structure. My app audio callback is calling everything that is being called on LinkHut example, except the fill buffer with click function.

I'm listening to tempo changes in session and changing my app tempo according. It happens that when I modify the tempo in my app, it will cause a new tempo proposal which triggers a tempo change in session, with a tempo that it is inferior with the tempo I have proposed. This cause my application to be stuck in tempo.

How should I handle this case?

Thanks,

Nuno

[lijon]

I solved it by having a separate proposeTempo variable, that is set only when the user changes tempo. The audio callback then detects that this variable has been set, and proposes a new tempo.

    Float64 newTempo = clock->_proposeTempo;
    clock->_proposeTempo = 0;
    if(newTempo != 0) {
        ABLLinkProposeTempo(clock->_linkRef, newTempo, clock->_hostTime);
    }

When my LinkSessionTempoChanged callback is called, I only set my tempo variable and not proposeTempo.

On Mon, Mar 21, 2016 at 11:14 AM, Nuno Santos notifications@github.com wrote:

Hi,

I'm having a problem. I have implemented Link as in Link Hut, with the LinkData structure. My app audio callback is calling everything that is being called on LinkHut example, except the fill buffer with click function.

I'm listening to tempo changes in session and changing my app tempo according. It happens that when I modify the tempo in my app, it will cause a new tempo proposal which triggers a tempo change in session, with a tempo that it is inferior with the tempo I have proposed. This cause my application to be stuck in tempo.

How should I handle this case?

Thanks,

Nuno

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Ableton/LinkKit/issues/16

/Jonatan http://kymatica.com

[brs-ableton]

In the LinkHut example, only the user action causes a tempo proposal. The tempo callback only updates the displayed bpm. So that's why this isn't an issue in LinkHut. But I agree that we should do more to prevent this loop from happening. The problem is right now we don't suppress the tempo callback if the tempo is set to the same value. I consider this a bug and we will fix it in an update. In the meantime I think something like @lijon's workaround also makes sense.

[sinosoidal]

Jonatan, I was already doing that. The LinkHut example does precisely the same.

I was however being dummy as the propose tempo function was being declared with a int bpm argument, so the number got always rounded and I couldn't get out of that tempo since my tempo proposals were always float.

Brent, I don't know if this should be considered a bug after all.