dlbond

Exciting new tools with transport. Thanks Cycling. 

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?

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

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? 

Example provided.
Thanks in advance,
dlbond

timepoint-behaviour

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.

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" 

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.

Chris Muir
cbm@well.com	
http://www.xfade.com

> There is no such thing in the new timing world as an absolute time 

Thank you. Please forgive my confusion. 'translate' led me to believe 

Now i see Max has both relative and absolute time systems. Oil and 

> 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!

timepoint behaviour