timepoint behaviour

Apr 29, 2008 at 12:25am

timepoint behaviour

Greetings all,
Exciting new tools with transport. Thanks Cycling.
Can anyone shed light on this?

First I notice that when one sends a “metro @autostart 1″ a ms time after it starts, it falls off track with the transport and continues banging after the transport turns off. This is understandable I guess. Getting it back under control is tough but possible.

But I wonder why a “timepoint 0:00:10″ would not bang on time if the tempo is changed. Isn’t 10 seconds a constant regardless of tempo?

Sometimes timepoints will fail to bang at all, especially when checking help files, reading doc, online, etc. How can one best maintain consistency and accuracy when working with these objects?

Example provided.
Thanks in advance,
dlbond

– Pasted Max Patch, click to expand. –
#37357
Apr 29, 2008 at 1:02am

The timepoint object only works with tempo-relative time values.

time attributes of timepoint can be specified in absolute time, but such a time is immediately converted to tempo-relative units. Look at any of the timepoint objects in your patch in the inspector, and then look at the available choices in the units pop-up menu.

There is no such thing in the new timing world as an absolute time of N seconds.

Times in seconds are always intervals, e.g., they exist with respect to some reference. What would that reference be? I suppose you were imagining that it would be 10 seconds after the transport started, but it just doesn’t work that way, because the tempo could change. If you really want a delay of 10000 ms after the transport starts, you don’t need a timepoint object at all. Just make a delay 10000 that is triggered from the gesture that starts your transport.

David Z.

#129047
Apr 29, 2008 at 1:07am

On Apr 28, 2008, at 5:25 PM, dlbond wrote:
> First I notice that when one sends a “metro @autostart 1″ a ms time
> after it starts, it falls off track with the transport and continues
> banging after the transport turns off. This is understandable I
> guess. Getting it back under control is tough but possible.

As I understand it, which may be a flawed understanding, metros with
time values are NOT part of the metrical time world. Changing the
tempo of how long 108 ms is does not make sense, so when you send a
metro an absolute time value, it disassociates itself from the
transport and starts behaving like an old-school Max 4 metro.

I’m sure there are things I’m either leaving out, or don’t have a firm
grasp on myself, but I think that “metrical time” and “time time”
don’t mix.

-C

Chris Muir
cbm@well.com

http://www.xfade.com

#129048
Apr 29, 2008 at 5:25am

> There is no such thing in the new timing world as an absolute time
> of N seconds.

Thank you. Please forgive my confusion. ‘translate’ led me to believe
there was some kind of equivalence.
Now i see Max has both relative and absolute time systems. Oil and
water. Brilliant!

Sorry for the yapping…
dlbond

[a patch to demonstrate the lesson here]

– Pasted Max Patch, click to expand. –
#129049

You must be logged in to reply to this topic.