Live API question: building a timer

[prebentious]

Hi. I'm trying to build an accurate timer that correctly reflects tempo changes, but I'm having trouble. I found two possible solutions in the LOM (live_set current_song_time and live_set current_smpte_song_time) which I thought might help, but I'm getting strange behavior. If you want to help me, please paste this into an empty max device, draw a tempo ramp in Live, and watch what happens. For me, it gets off the correct time as soon as the tempo changes. Does this happen for you? Do you have any suggestions or leads for me?
Thanks a million!


----------begin_max5_patcher----------
727.3oc0X1saaBCEG+ZxSgEWyh7GP.xcauFSUQDvK0U.FANcoqpu6CaCMr1v
GMArxjR.wwNN+8OeNGeLutxxdO+DsxFrE7Sfk0qqrrTljFrZd1xNK5TbZTkp
a14zey2+jsitIA8jPYNiJJ4.DrsghHQ7ir7C6JowB836hcWCc.tP4UOr7JJX
MD7PyO4W7bQE6OTYuQxNoMmeLikmREp+d7Yi7ihVqnFqrDkVp022P91cF17n
L0vZ+8RVTJ3G7zj1l0Ci3kBpVk16ixOXCdP15aqVIu3LQzjQqphNP+DaNPE6
hOVVRyE6pxJDzcU7ZxHXYT.DB2V+AQ1hBeGdorbZL+Xtn6TtehhHa5bC6uXL
cy0xz4kmwQoofAg5EAIY.PBUNkaz3D5KuQBWLNhMKG6IjMk8LcccCRJL.Z70
QpXcXa3BG15ce3hcfK3.If1UQGhNdZrnYTCo1rXvI39wuolEONNWBBTNMnqx
oAcQtPt.WBuZt3z7cN4i.f.6GhMPUZFctaBds2rwF7mYCFdsrgUm0z4V1NrO
2GdThZPGkPZmGuYz44BAUXj4KTnWGm8C53fC2zlfY4cbPt2DWbVhBoHtqCCQ
tP7PPpIKrq1EBtvojI2GojGOlpw4AZhXJu6nZum3F4DD9bEfK8F4++rOdCVz
gQK993v6p8wapOthV9LsbnHKOcZYT2h.mmJjuPdYxMwnYM1pnjWPKEu.d+bX
sm.6qdPVLLn64uHK74XQyS7mRcp43GdCJpYnz9+B0J9wx31gpIO.37bLgVIX
4QBFOuSejAEc5zirjDpp8VFjwRJ30Eq0ngdVgmpj7lhjbMpjHSQRxNgLljjE
MNplvlckS82gFiSAlWSit14aTMIOs33Zxyn9SnIkIHzrbxeJZBaVMMozSaL6
Zm6Dh6LaX2GRP2ClPeMMQfdxSb5oe4EH+1GtUshmZ3nA42TRuSLqjfSTRWqi
e8Cus5u.pV0BnB
-----------end_max5_patcher-----------

[pukunui]

You'll be better off using the transport object for getting timing information from Live's transport.

-A

[prebentious]

Hi Andrew,
Yes, the transport object is handy, but it only works with metrical values. I'm trying to make a timer that counts minutes and seconds. If I use the translate object to convert info from the transport object to absolute time values, it becomes inaccurate if I change tempo. the current_set_time property in the LOM says that it returns the current set time in milliseconds, but it too gets messed up when the tempo changes dynamically. Same with get_current_smpte_song_time. Do you have any suggestions that might get around this limitation?

[Gregory Taylor]

So you're saying that a transport object driven from a metro whose raw ticks output feeds a translate object isn't outputting hh:mm:ss properly?

[prebentious]

So you're saying that a transport object driven from a metro whose raw ticks output feeds a translate object isn't outputting hh:mm:ss properly?

It works if the set's tempo stays constant. Try doing what you say when the tempo is automated by a ramp. Watch the output of the transate object and compare it to the time ruler under the track display.

I think what happens is that the translate object uses the current tempo but doesn't regard any tempo changes earlier in the set, so it loses accuracy when there's a tempo ramp.

[Gregory Taylor]

What happens if you drive the tempo change using Max rather than relying on the automation ramp?

[pukunui]

Yeah I think this is the way translate works.

OK - so what you want is absolute clock time regardless of tempo changes? I'm curious why - what's your need?

To workaround, maybe you could just run a

metro n

Where n is the granularity you require, so if you want your time accurate to the 1/4 second, use

metro 250.

You might stop and start this timer with something like

<pre><code>
----------begin_max5_patcher----------
410.3ocwUE0SCBCD9Y3WQSeFWnEvsYxdP+aXVLEnB0.sDZINcY9a21xvMWl.
FmrWZC2c85222cWYqqCLVrgJgf6.OBbb1553XMYL3r+aGXIYSRAQZCCF2nTB
Nzq0UEQkjy3YOUSSTsoIBgm46APAglMre2JX89yvRsIRD+xMX+tDIZTETk5s
JZaVfwDdF7qyvaJYbc.VLfNXr8XsVMF245ZV7tTjIDe63IC55RFN8UML5vfh
twxAHMMi9wHnneX6VTubD2OG8NkqOK3JNozFD79ZFo.djGI6cqGDZVzxHzh4
iWgvWNEZ0pO.9yFVhlaK+gg8JPA+n.IYYbM8ujRC9+t4IIWWMGS6SvRyZDx1
Cs37ZCZ4ePa.OHJROq.YpJWiAqphlrpbhTTOlwK6ihy6WeVLj9nGuJXR0DnS
GOdYuM8EyO8OEV5Zr+cwSJZpS5PdWgGbfxoTohwIJl9o2CAYlbNJnbVZJ05u
C0krzJAiq1CBv5yVJGKlLujAPCgI+oGSCpSnoESAiAS3IESlAkAwzIMc+NLo
+Xm6mT3Xa3B
-----------end_max5_patcher-----------
</code></pre>

And use a bunch of counters to add it all up.

Something like this should keep absolute time while you are stopping and starting Live's transport, jumping around in the timeline etc. as long as time is always running forward. If you need it to report correctly while you are editing the song, in other words, if you want to go back to edit points and rerun things, then you'll probably need to create some kind of hand rolled marker system which resets your clock with timepoints.

The LOM docs are incorrect, sorry. Current_set_time from the API is metrical.The SMPTE thing might be a bug, I'll look in to it.

-A

[prebentious]

Hi Andrew,

Why do I want a counter? Well, I work with lots of choreographers and filmmakers, and it helps them to have a big counter to refer to when we're working. The timeline in the arrange page just isn't as convenient for them.

Thanks so much for your example, but sorry to say but I don't really understand how to hook it up to the metro and use the counters. Regardless, the limitations you describe would still be too severe to use with my clients, a;though it could be a cool tool for live use. Maybe Ableton will expose the absolute time in a future version of the API.
Thanks again!

[kleine]

Does this help? It´s a very simple time counter-
http://tinyurl.com/yepaqux
It has minor flaws (graphically)

Best
Christian

[Machinate]

Does this help? It´s a very simple time counter-
http://tinyurl.com/yepaqux
It has minor flaws (graphically)

Best
Christian

You want to download the following file:

http://rapidshare.com/files/327628954/ck.timer.amxd.zip | 4 KB

Unfortunately right now our servers are overloaded and we have no more download slots left for non-members. Of course you can also try again later.

I can host it for you, Christian? I wouldn't mind.

[prebentious]

Wow! Thanks Christian. This is almost exactly what I'm looking for. The only problem is that it's only accurate when I start at 1.1.1. I'll keep working and see if I can post a fix.

[kleine]

I can host it for you, Christian? I wouldn't mind.

sure...

[Machinate]

http://wetterberg.dk/uploads/ck.timer.amxd.zip

[koeniglich@gmx.at]

did anyone of you find out in the meantime how to get absolute time values using the arrangement mode - independent of bpm changes? i'm desperately looking for a solution!
the current "playing_position" of a track in the arrangement mode would also be very helpful - so we could "un-warp" the track and use it as a time master...

thanks!!

[Razzkazz]

The only way I have found to display absolute time is to create a video, for my usage, 1 hour long and burn a timecode display on it. Then import that into your session and display it to see the exact time.

For my use case, I also needed the start position offset from 0:00, so I just move the video to my desired start time and I get absolute time.

Seems crazy that this is the only solution (that I could find), but I have tried many options using the Transport object, the API plus translation, with no success. A bpm change totally messes up the timing.

For anyone working with video, it's a nightmare.