How to determine the current position in the bar?
bolau opened this issue · comments
Hi, thanks for providing this library, the example worked out of the box for me.
Currently, my code listens to MIDI clock messages generated by Ableton to "slave" my code to Ableton.
Now I would like to use Link to replace MIDI clock syncing, so I use link.sync(1/24) to get a clock-message-like signal, that works fine.
In addition, I would like to get the current beat count. I looked into the code and saw the functions to retrieve the attributes beat, time, phase, and so on. This enabled me to check, where on a given beat I am, e.g., 7.0 is precicely on the beat, 7.5 an 8th note after that, and so on.
But how do I determine, where in a given bar I am, e.g., that 7.0 is the 2 in a bar? It seems that beat and the return value of sync just counts from 0, but the relation to the beat is not fixed.
Thanks for any help,
Boris
I found that I can increase quantum, e.g., to 4. If that matches the time signature in Ableton, the beat number or the return value of sync modulo the quantum gives me the position in the bar. But is there a cleaner way?
Hi @bolau , there is no way to get the beat count of a peer (Ableton Live in your case) with Link, but yes, matching quantums on the peers will ensure you have identical phase with modulo the quantum.
A cleaner solution would be resetting the local counter on transport start (currently missing from this implementation, but to be added soon) - this will provide a bit more possibilities, i.e. synced transports with unspecified quantums.
Your name is familiar, have you been part of the SuperCollider community a while ago?
Hi, thanks for getting back to me.
Resetting the counter on transport start would be great. I thought I could do something like that using set_start_stop_callback, what that's never called. Probably I'd need to sync start and stop for that to work, and I don't really want to do that. Well, the quantum does help for now :)
I've never used SuperCollider, but maybe we've met in one the Teensy, Axoloti or Max/MSP forums?
Yep, by design enabling start/stop sync would be required for resetting the local count.
This would ensure that Python scripts that are designed to run in sync with a DAW would have the means to do so (schedule a coroutine in the start callback and rely on the counter being reset), while interactive scripts that just play along ignoring the other peers' transports also won't have their state/counters reset.
Not sure what exactly is your use-case, but yes, matching quantums on both peers is probably a good solution for now.