Timer Question
According to the manual, [timer] outputs time in milliseconds. Maybe I'm doing something really strange, but when I use [timer] to count the time between a note on and a note off, I get the result as a float with multiple places to the right of the decimal point. If I manually trigger the timer, it works like I think it should. I realize I can use a number box after the timer to make it a whole number, but the behavior seems strange to me.
Quote: bkshepard wrote on Fri, 20 April 2007 21:05
----------------------------------------------------
> According to the manual, [timer] outputs time in milliseconds.
----------------------------------------------------
So what's the problem?
Since Max 4.something all timing values have been float to support sub-millisecond accuracy.
The only surprise is that UI events are, apparently, always reckoned as taking place at some integral millisecond time. I can imagine a couple of reasons, but only the programmers at Cycling know for sure.
-- P.
PS: Take the "sub-millisecond accuracy" with a few grains of salt. Timing precision depends upon system load and a bunch of other stuff. And the values are never accurate to six decimal places (that would be nano-second accuracy).
Thanks Peter,
It's not really a problem, it was just more of a puzzle. I hadn't realized a change to sub millisecond timing had been made. Just for my clarification, does that mean, then, that a UI triggered [timer] will give millisecond timing, while an internally triggered [timer] will give sub-millisecond timing? Thanks for the info.
Quote: bkshepard wrote on Sat, 21 April 2007 00:32
----------------------------------------------------
> Just for my clarification, does that mean, then, that a UI triggered [timer] will give millisecond timing, while an internally triggered [timer] will give sub-millisecond timing? Thanks for the info.
----------------------------------------------------
Your demo patch seems to indicate as much. But I don't know for sure.
BTW, [timer] is tied to Max' "logical" time, used by metro & Co. As I said, you need to take all of the time information from this source with some grains of salt... The Max internal timer is a complex beast.
You may want to look at cpuclock as an alternative to timer.
Brian Shepard schrieb:
> Thanks Peter,
>
> It's not really a problem, it was just more of a puzzle. I hadn't
> realized a change to sub millisecond timing had been made. Just for
> my clarification, does that mean, then, that a UI triggered [timer]
> will give millisecond timing, while an internally triggered [timer]
> will give sub-millisecond timing? Thanks for the info.
I think this would be pretty irrelevant, as timer can't be more precise
than the scheduler tick (which is more likely 2 ms depending on your
performance settings).
Its only more precise over a longer measuring period. If you add up
those intervals with integer precision you would accumulate truncation
errors whereas if you add the floats the error is at least smaller...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Peter, Stefan,
Thanks for all the information. Both of you make great points. I will take a look at the cpuclock as well.
This all came about because--as part of a little demonstration--I was using a [prepend set] to write the output of [timer] to a message object. I noticed that sometimes I got whole numbers and at other times I got floats. Being the anal-retentive type that I am, I wondered why. Then I realized that the difference came about based on whether I triggered [timer] or something inside the patcher did. I apparently missed the memo on timing resolution going to sub-millisecond resolution and wasn't aware that [timer] even did that. That's what prompted my curiosity.
As always, I got wonderful information from the group. Thanks again.