Measuring(translating) Time HH:MM:SS Max4Live
hallo!
Dear forum users.
This is my first post here.
I've got question about time measuring time inside of ableton live.
I mean translating play position from bars..... to HH:MM:SS
I used to test couple things.
1. Using [transport] and [translation] --- ticks to hh:mm:ss
2. Using Plugsync~
3. Using get_current_smpte_song_time
Everything works perfect but there is one main issue that i can't solve.
All of this patches works good when tempo of session is constant for example: 120bpm, 170bpm etc.
Problem comes when tempo become automated. In this scenario all of this tools are not usable,
because they are not reacting for tempo changes and
Any ideas?
I will be very grateful!
Steve
I found something like this? But it doesn't work for me. Or i don't understand it correctly.
The formula is 60000 / (BPM * PPQ) (milliseconds). Where BPM is the tempo of the track (Beats Per Minute). (i.e. a 120 BPM track would have a MIDI time of (60000 / (120 * 192)) or 2.604 ms for 1 tick
PPQ of Live (and Max) is 480.
So for 120 BPM you get 1 tick = 1.041667 ms.
Thanks!
This is patch that I'm working on. Still I have the issue when tempo is changing. I done calculation to get value of tick in ms depending on tempo , but still its not working properly when tempo is automated.
Hope someone help!
why don't you use sample count ?
Or is sample count in Live & plugsync NOT sample count ?
sample count out -> translate samples hh:mm.ss.
If that does not work than plugsync does not output sample count.
Thanks. Good idea. I need to figure out how to get sample counts. I think [plugsync] does not output sample count [transport] too.
Any ideas how to get sample count?
is 8th outlet not named sample count ?
It actually dous not matter what format it is,
samples ms, ticks or whatever,
if it represents elapsed time from the beginning
of the timeline, then you can use it to get hh:mm:ss
I don't use Live so can't tell you, but is that not a matter of
10 seconds to check it ?
The sample count of [plugsync~] runs continuously as soon as Live is started, so it doesn't represent the elapsed time of a song.
If the song plays from start to end without jumps, you can use [cpuclock].
using cpuclock won't help much when playback gets rewinded,
or jumped to another location etc.
I don't use Live at all, but some months ago I helped someone
with SMPTE output to DJ decks from Live.
From what I remember both rawticks with bpm calc worked
Also call get_current_smpte_song_time
to live.object did not suffer any problems with tempo or measure
changes .
Guys, I actually did all these things before I ask you for help! :)
I'll enclose a video by showing the problem details.
I hope You'll understand me better now and You'll be able to advise me on how to deal with it.
I just installed that really crappy Live software to check this again.
The so called Song SMPTE time which should be
elapsed real time expressed in whatever ms or SMPTE format does not respect
simplest rule - to calculate elapsed time by means of elapsed bars, beats
and their tempos.
If you run 8 bars of 4/4 temp 120 and than have tempo 130,
at the moment ruler reaches bar 9 it sets elapsed time as if tempo was
135 from the beginning. What a nonesense.
So as far as I see it it is not possible to display elapsed real time
using any kind of live internal measurement.
Maybe that is why it can't output midi time code, but only beat clock.
Crap...
Thanks for your sacrifice!:)
I'm not math mastermind but I have a filling there is some formula to compare variables like ticks bpm and maybe beats or something that we can watch to get a proper result even if tempo change.
We know how to calculate bpm and ticks to get in a result gap between ticks for example in ms so, maybe there is something that we didn't notice.I think maybe there should be something that comparing tempo changes and using it to measure time differences. Maybe it's nonsense but I won't give up so quickly :)
I am sorry to say it, but this seems to be an issue since 2004
at least that was one of the search results for ableton live real time
display user forums - complains.
That is 15 years ago.
Whar are this guys doing ?
It is a shame to call it a DAW.
If this is sooo important to you make audio track with
some kind of smpte time code
and decode it to visible hh:mm:ss and that's it.