-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove 20BPM minimum limitation #59
Comments
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. |
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. |
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. |
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. |
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:
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. |
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. |
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. |
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. |
https://www.ableton.com/en/link/ Ableton Link keeps devices in time over a local network. This change replaces other methods of synchronizing Tidal sessions with each other. Tidal sessions (and other Link enabled units) will now automatically connect and synchronize their timelines. To stop Tidal from connecting to other peers, configure cEnableLink = False. Ableton Link has a 20 bpm lower limit: Ableton/link#59 COMPATIBILITY NOTE: Ableton Link is a C++ library. The support for using C++ libraries in Haskell has improved over time, but toolchains that are still in use by many might not be compatible with this change. To ensure compatibility, please update your Haskell toolchain. Use Cabal version 3.4.0.0 or later. On Windows, use GHC 9.4.1. (see https://gitlab.haskell.org/ghc/ghc/-/issues/20918)
https://www.ableton.com/en/link/ Ableton Link keeps devices in time over a local network. This change replaces other methods of synchronizing Tidal sessions with each other. Tidal sessions (and other Link enabled units) will now automatically connect and synchronize their timelines. To stop Tidal from connecting to other peers, configure cEnableLink = False. Ableton Link has a 20 bpm lower limit: Ableton/link#59 COMPATIBILITY NOTE: Ableton Link is a C++ library. The support for using C++ libraries in Haskell has improved over time, but toolchains that are still in use by many might not be compatible with this change. To ensure compatibility, please update your Haskell toolchain. Use Cabal version 3.4.0.0 or later. On Windows, use GHC 9.4.1. (see https://gitlab.haskell.org/ghc/ghc/-/issues/20918)
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
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
|
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. |
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?
The text was updated successfully, but these errors were encountered: