Workarounds for indeterminate ordering of downbeats and time signature changes
Hello!
I am trying to create a M4L patch whose core functionality is related to the ability to report the duration of the current measure when a downbeat happens. So for a measure of 4 4 at 60bpm, on each down beat I want to report 4000 ms. However, I would like this to be robust towards time signature changes. (I experimented specifically with 4 4 -> 5 4 -> 11 16 -> 34, one measure at a time.)
I'm afraid this might not be possible, according to some of my testing. Here is what I tried.
First, I used transport attached to a 16n metro. What I found was that time signature changes are reported after beat one of a transport cycle. Further testing in conjunction with plugsync~ determined that it took almost 10ms for the time signature to register after the downbeat.
Second, I used plugsync~ in the hopes that the tighter timing would lead to greater accuracy. What I found was the the value for the current beat became very garbled after a time signature change.
I'm curious if anyone has attempted this and found a work around. I suspect that I might just have a weird use case, and that these bugs are +10 years old.
I don't use Live but had a look from time to time to check
sync with other apps, and one thing allways disturbed -
live does not report absolute time, nor is capable of reliaby
reporting tempo/ time signature changes.
No idea if that changed in live 12.
If you would try to use plugsync~ raw tick count to count beats,
then capture time signature list from live using LOM or scripting,
(which I have no idea if it is possible), and so detect
1st beat in the bars ?
hello Thomas!
You're right, plugsync~ and other objects have a gruesome time figuring out where they are in the beat, and ticks as such - on an absolute level - are a mess at figuring out where they are in the beat when time sigs switch.
It's weird to look at the "current bar" and "beat count" outlets of plugsync~ being demonstrably wrong in this scenario. I think you're right in that this is a very old bug, and I believe plenty of people have struggled with things that keep time in Live in part because of these issues.
Instead, one might look at ONLY the "time sig" and "tempo" outlets.
I set up a quick scenario that samples the tick value when we get a time sig change, and find it's extremely fast and accurate. Pls refer to this attachment - I hope I understood your problem correctly, and that this might be useful to you?
I think this implementation falls apart if tempo changes occur though, since you'd need to update the list then, but then your lack of updates from changes prevent this.
alternatively, like Source Audio says, one might look at the LOM for this, time_signatur_numerator etc.
a combination of beat/bars stuff and overall signal count can often get you there.
My goodness, I didn't expect everyone to be so helpful! Thanks!
@Source Audio
I didn't think of using LOM. Seems daunting, but maybe in the future I'll have a look!
@Wetterberg
Thanks a smart solution. The issue I have is that it doesn't report a down beat in absence of a time signature change. Then again, maybe there is no need to settle.
@Roman Thilenius
There might be something deeply true about this, that Live/Cycling didn't provide for this edge case because it is an edge case, and I should provide for it myself through some clever math (which I am not always good at.)
Thank you all for your help!