I’ve been playing around with making a “Play from Last Play Point” patch, and I notice that when you <get> the current_song_time Property, it only returns the full float if Live is running – if if Live is paused, it returns a rounded-off integer to the nearest second. Also, the numbers are based on a fixed temp of 60BPM and don't take Live's tempo into account (i.e. at 120BPM they’re off by half). Maybe there's something wrong with my tiny little patch calling the function, but I don't think so...
brian
[c74] current_song_time Property bug?
Re: current_song_time Property bug?
Current_song_time gives you the time measured in
beats .
So, 1.1.1 in Live is 0.0, 2.1.1 is 4.0 (with a 4/4 time signature)
and so on. If you call get_current_beats_song_time,
Live will return a struct that contains the time split
up into bars, beats, subdivisions, and ticks.
If you have a patch which shows otherwise, please let us have a look at it.
-A
beats .
So, 1.1.1 in Live is 0.0, 2.1.1 is 4.0 (with a 4/4 time signature)
and so on. If you call get_current_beats_song_time,
Live will return a struct that contains the time split
up into bars, beats, subdivisions, and ticks.
If you have a patch which shows otherwise, please let us have a look at it.
-A
Re: current_song_time Property bug?
Hi, thanks for getting back.
Maybe I'm reading the API wrong, but according to the "m4l live ref objectmodel.maxref.xml" API doc, there's a Live object model Property "current_song_time" that you can get/set/observe - it returns a Float that represents "Live set play position in milliseconds"
I think you might be referring to the "Get-Current_beats_song_time" function? (that's similar but not not what I'm talking about).
I could be mistaken, though - new to max. I'm happy to send you the patch (I'd have to email you an attachment, though, <save as text> on the current beta is not working for me).
brian
Maybe I'm reading the API wrong, but according to the "m4l live ref objectmodel.maxref.xml" API doc, there's a Live object model Property "current_song_time" that you can get/set/observe - it returns a Float that represents "Live set play position in milliseconds"
I think you might be referring to the "Get-Current_beats_song_time" function? (that's similar but not not what I'm talking about).
I could be mistaken, though - new to max. I'm happy to send you the patch (I'd have to email you an attachment, though, <save as text> on the current beta is not working for me).
brian
Re: current_song_time Property bug?
I think we have a doc error.It works the way I describe, but I can see it says ms where you mentioned. Sorry about that.
If you need absolute time for some reason, you'll need to use the translate object or poll transport.
Most of the transport stuff in MFL and Max is designed to work with the metrical time of the set or song.
Thanks for the note, I'll log it.
-A
If you need absolute time for some reason, you'll need to use the translate object or poll transport.
Most of the transport stuff in MFL and Max is designed to work with the metrical time of the set or song.
Thanks for the note, I'll log it.
-A
Re: current_song_time Property bug?
Hi Andrew
That's funny, for me it's behaving as the documentation says - for example, at 60bpm, 10 seconds occurs at bar 3, beat 3 - and from there it returns a float "10." (not 3.3.0 or anything like that).
I was mistaken about one of the bugs I initially mentioned - it *will* return the exact (non-rounded) full float if paused at odd places, my bad - but for me, it *is* returning time, not bars/beats - and the bug is that it's based on a fixed 60bpm tempo. So if Live is at other tempos, the numbers are wrong. I'll send you the .axmd - it's a tiny patch but maybe I'm using it wrong somehow?
brian
That's funny, for me it's behaving as the documentation says - for example, at 60bpm, 10 seconds occurs at bar 3, beat 3 - and from there it returns a float "10." (not 3.3.0 or anything like that).
I was mistaken about one of the bugs I initially mentioned - it *will* return the exact (non-rounded) full float if paused at odd places, my bad - but for me, it *is* returning time, not bars/beats - and the bug is that it's based on a fixed 60bpm tempo. So if Live is at other tempos, the numbers are wrong. I'll send you the .axmd - it's a tiny patch but maybe I'm using it wrong somehow?
brian
Re: current_song_time Property bug?
Hey Brian,
A couple of things.
- if it were really reporting in ms you wouldn't see 10 at bar three
- I think testing at 60 bpm is the thing which is the sticking point.
Here's my test patch. I'm observing the current_song_time and setting it.
It reports the time in accumulated beats, so beat 10 is 3.3.1 in Live's transport in 4/4.
If you change the tempo around however you like, you'll see the results are always the same.
Cheers
Andrew
<pre><code>
----------begin_max5_patcher----------
724.3oc0XtsbaBCDF9Z7SgFldoqGjDG6csuFcx3ACJwJEj7.xoNMSd2qPBWa
GKbn1.FtgAzI92O1c0hdalk8J9NRoM3afeBrrdalkkpopFrpe1xNOdWRVboZ
X1Lxu4qd1dttKAYmP0bFONcUL6o8cPSUMKG5Ww6aiuUjQDhW2PzuPa0D.OT2
8iblnj9GUmPmEN0MuIVjrlxdZYAIQnmHDFI6F.wUW87T2Gtv4eqDaaNkIeUJ
ECOZ4Yw4pk296Ez3LvO3Yo1GliVe5IU036ylUcYdKISBOOmvDmgljLZxu.xW
74nw09+11Q99J6EorcXOX6NWgsmSJKiehbls6tvjCgeidDWi2fGNPQA0ULZg
m7d+lHBZn7FZhHHiDwsSIhqe3DhHXiDA2s9HNnIDQbLRDXmRDbjNpweRPDnI
hfh51nFLdBQDjQmDTXGmZUAi.mogShYjDzG6135NIPRIQ.R1VTHqKYYIWZHB
ZNA7EnIN0s4WbcUtNQ5chvn8gV2YP8XFWtHFLeXyQNx4DKKq65qW00QWip10
A4D0CUsgtBXzPs7BvJPlID4e4J4mecdJvHEcBQGEQc+YSSQTaJ3aHEhWOOrx
Dw75zXpZRA0+3CTmCZDDT0z+DRegrfupjT7BovDctPMd2luDDqR6DftbfF5N
GnUCnmqjuA7f5VmGjyg8x8h5AxzkabQSAl1jB1saRgzQR9JmFOmIP3jzHVaf
KgWNR51hlb6uyZ.2kYlknATAokxpdLvn9IWrJGb.rmccTKqzCf8wCqSorp1O
EXk7sEI6Mu5CgCbPbojRAkEKnb1Qiw6jwrlllRTcumB4zzMbJSTKAvCF+30Z
E42BIUUT5PpI2QnlviPMAGeZp5z.FcZJbDpo17sqp1igTSAiONAaSbGLbX0T
UNS3moI7ICp20jWa3Dd34zmpogc+t1jJ3C5dTHIzf5M0JIAGTI0F+6aIMf7g
2m8WAGpxK.
-----------end_max5_patcher-----------
</code></pre>
A couple of things.
- if it were really reporting in ms you wouldn't see 10 at bar three
- I think testing at 60 bpm is the thing which is the sticking point.
Here's my test patch. I'm observing the current_song_time and setting it.
It reports the time in accumulated beats, so beat 10 is 3.3.1 in Live's transport in 4/4.
If you change the tempo around however you like, you'll see the results are always the same.
Cheers
Andrew
<pre><code>
----------begin_max5_patcher----------
724.3oc0XtsbaBCDF9Z7SgFldoqGjDG6csuFcx3ACJwJEj7.xoNMSd2qPBWa
GKbn1.FtgAzI92O1c0hdalk8J9NRoM3afeBrrdalkkpopFrpe1xNOdWRVboZ
X1Lxu4qd1dttKAYmP0bFONcUL6o8cPSUMKG5Ww6aiuUjQDhW2PzuPa0D.OT2
8iblnj9GUmPmEN0MuIVjrlxdZYAIQnmHDFI6F.wUW87T2Gtv4eqDaaNkIeUJ
ECOZ4Yw4pk296Ez3LvO3Yo1GliVe5IU036ylUcYdKISBOOmvDmgljLZxu.xW
74nw09+11Q99J6EorcXOX6NWgsmSJKiehbls6tvjCgeidDWi2fGNPQA0ULZg
m7d+lHBZn7FZhHHiDwsSIhqe3DhHXiDA2s9HNnIDQbLRDXmRDbjNpweRPDnI
hfh51nFLdBQDjQmDTXGmZUAi.mogShYjDzG6135NIPRIQ.R1VTHqKYYIWZHB
ZNA7EnIN0s4WbcUtNQ5chvn8gV2YP8XFWtHFLeXyQNx4DKKq65qW00QWip10
A4D0CUsgtBXzPs7BvJPlID4e4J4mecdJvHEcBQGEQc+YSSQTaJ3aHEhWOOrx
Dw75zXpZRA0+3CTmCZDDT0z+DRegrfupjT7BovDctPMd2luDDqR6DftbfF5N
GnUCnmqjuA7f5VmGjyg8x8h5AxzkabQSAl1jB1saRgzQR9JmFOmIP3jzHVaf
KgWNR51hlb6uyZ.2kYlknATAokxpdLvn9IWrJGb.rmccTKqzCf8wCqSorp1O
EXk7sEI6Mu5CgCbPbojRAkEKnb1Qiw6jwrlllRTcumB4zzMbJSTKAvCF+30Z
E42BIUUT5PpI2QnlviPMAGeZp5z.FcZJbDpo17sqp1igTSAiONAaSbGLbX0T
UNS3moI7ICp20jWa3Dd34zmpogc+t1jJ3C5dTHIzf5M0JIAGTI0F+6aIMf7g
2m8WAGpxK.
-----------end_max5_patcher-----------
</code></pre>
Re: current_song_time Property bug?
Hey Andrew -
Actually if it was returning absolute time, you *would* see 10 at bar3/beat3 at 60bpm (I assumed they were putting ms to the right of the decimal). But nevermind, I get it now - accumulated beats.... The mistake in the documentation and my running at 60 BPM, that combined to make it look that way... thanks for getting back so quickly!
brian
Actually if it was returning absolute time, you *would* see 10 at bar3/beat3 at 60bpm (I assumed they were putting ms to the right of the decimal). But nevermind, I get it now - accumulated beats.... The mistake in the documentation and my running at 60 BPM, that combined to make it look that way... thanks for getting back so quickly!
brian