Remove 20BPM minimum limitation

[cerupcat]

Is there a reason for the minimum BPM to be 20? I currently have users that require BPM lower than this and my app previously supposed it. Is there a technical reason to limit the BPM?

[fgo-ableton]

There is a technical reason to have a minimal BPM: The timeline must always progress. The number 20 just comes from the minimal tempo Live supports. And it is not possible to change this without breaking backwards compatibility.
There is an easy way for you to work around this though: If your user wants to run at a tempo that is out of the rage link supports, find a matching tempo to send to Link. I.e. the run at 12 BPM while setting Link to 24 BPM so you effectively run half time related to the other peers.

[brunchboy]

And, in the case where you can’t pretend that the timeline must always progress (for example, when synchronizing Link with Pioneer CDJs, and the DJ has completely stopped the player by holding down on the jog wheel, setting the tempo to 0 BPM), you can stop synchronizing with Link until forward motion resumes.

[cerupcat]

Thanks, i'll look into the running at half time. Unless I'm missing something, the downside is that if trying to sync tempos, it won't sync below 20. I'm also not sure how it'd work where if one person changes tempo below 20, let's say to 15, they'd end up setting other devices to 30bpm (since they'll run at half speed).

It might end up being simpler to disable link if trying to run below 20 bpm.

[fgo-ableton]

True, it won't sync the tempo below 20 BPM. This is a workaround to make apps still run in sync at tempo that is not supported by Link.
Disabling Link will lead to the apps not being in sync. IMHO this makes sense when running at 0 BPM locally, but not so much when there is still audio generated, that would be perceived as out of sync.
Maybe give both solutions a try, and do what makes most sense in the context of your app.

[cerupcat]

Thanks @fgo-ableton. In my case, I have an iOS/Android metronome app and users can sync the metronomes to follow along. My concern with keeping sync on when setting below 20 is there would be potential unexpected behavior (from a user's perspective).

User 1:

• Set the tempo to 15 BPM
• Sync gets set to 30 BPM
• Set locally to 15 - half time.

User 2:

• The device gets synced to 30 BPM (from User 1 BPM change)
• Changes tempo to 15
• Sync gets set to 30 BPM
• Set locally to 15 - half time
• User 1 Device changes to 30 BPM (due to change on User 2)

Essentially, each user changing below 20 BPM would reset the value that the previous person had set. Since there wouldn't be a way of distinguishing if the new BPM should be 30 or 30 half time. So, I'm just unsure if the UX and potential confusion would make sense to keep. Maybe there is a good solution here, I'd just need to think more through it.

[fgo-ableton]

I see. In case of a metronome it probably makes sense to always run at the "real" tempo. So I guess limiting it to the range Link supports when it is enabled makes most sense.
Maybe some use cases could be solved with an explicit half time setting in the app - maybe that's also too complicated.

[brunchboy]

I went through similar trains of thought when I gave up on the idea of running at multiples of the tempo; when the DJ is braking the CDJ, you would have to quickly cycle through divisors, you would be briefly forced to half, ⅓, ¼, … 1/1000, a millionth, etc. time. It is just impractical, so I break the link with Link when braking playback, and resume it once playback has resumed and returned to the Link legal range. But it is the only part of the Link protocol that seems arbitrary and awkward. It is a pity that it cannot be changed without breaking compatibility.

[cerupcat]

Thanks, guys. I appreciate those thoughts. I agree @brunchboy that trying to multiply tempos on the fly wouldn't be viable in these cases.

I'll have to look into it more. It's the classic dilemma of adding complexity for something a small segment of users wants, but I might have to bite the bullet.

[Zalastax]

I can't contribute code to this but I hope I can contribute to the good discussion.

Regarding that "the timeline must always progress": this statement would hold also for an extremely low bpm. How low could we go without changing the network protocol? From

link/include/ableton/link/Beats.hpp

Line 36 in 41d9aa1

: mValue(std::llround(beats * 1e6))

I believe BPM value is stored as microBPMs? Would 1 microBPM work as the lower limit or would that cause something else to break in the protocol?

Regarding the inability to change the limits without breaking backwards compatibility: would it be possible to work around this by only allowing lower and higher bpm in sessions where all clients use a new Link library version? Perhaps bpm clamping

link/include/ableton/link/ClientSessionTimelines.hpp

Line 31 in 41d9aa1

inline Timeline clampTempo(const Timeline timeline)

could be negotiated among peers and old peers get the current default range (20 to 999)? We would need to design for the case where a new peers joins and the bpm is outside the range. Do we reject that peer or do we force the bpm to be within range?

[fgo-ableton]

There is no way to change this without breaking backwards compatibility. Also Link has no notion of peer capabilities at all, so adding this would make stuff way more complicated.
I also don't think introducing the ability for peers to support different tempo ranges would work, as this would mean the session potentially would have to change tempo when a new peer joins.