Adam Murray

When I run this patch the message boxes should both display 2.1.0, but the quantized metro shows 2.2.0. If I start the metros at 1.1.0, it sometimes works properly. With any other autostarttime the quantized metro is one beat late.

bug-quantized-metro-misses-first-beat

On Jun 29, 2008, at 11:58 AM, Adam Murray wrote:

> When I run this patch the message boxes should both display 2.1.0, 

> but the quantized metro shows 2.2.0. If I start the metros at 1.1.0, 

> it sometimes works properly. With any other autostarttime the 

While I have seen problems with the new timing world, and have 

reported at least one that hasn't been addressed yet, I'm not seeing 

the problem that you describe. FWIW, here's a slightly edited version 

of your patcher that made it easier for me to test:

On Jun 29, 2008, at 11:58 AM, Adam Murray wrote:
> When I run this patch the message boxes should both display 2.1.0,  
> but the quantized metro shows 2.2.0. If I start the metros at 1.1.0,  
> it sometimes works properly. With any other autostarttime the  
> quantized metro is one beat late.

While I have seen problems with the new timing world, and have  
reported at least one that hasn't been addressed yet, I'm not seeing  
the problem that you describe. FWIW, here's a slightly edited version  
of your patcher that made it easier for me to test:

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

> While I have seen problems with the new timing world, and have reported 

> at least one that hasn't been addressed yet, I'm not seeing the problem 

> that you describe. FWIW, here's a slightly edited version of your 

> patcher that made it easier for me to test:

The edited version let me reproduce the problem though. But I needed to 

stop the metros first, so I added a 0 message to stop the metros before 

starting the transport. the quantized will miss the first event (2 1 0.) 

Chris Muir schrieb:
> While I have seen problems with the new timing world, and have reported 
> at least one that hasn't been addressed yet, I'm not seeing the problem 
> that you describe. FWIW, here's a slightly edited version of your 
> patcher that made it easier for me to test:

The edited version let me reproduce the problem though. But I needed to 
stop the metros first, so I added a 0 message to stop the metros before 
starting the transport. the quantized will miss the first event (2 1 0.) 
on my Powerbook (PPC, 10.4.11, 5.0.3)

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


for what its worth, I get the same behaviour as Stefan when using his patch

On Mon, Jun 30, 2008 at 10:04 AM, Stefan Tiedje 

>> While I have seen problems with the new timing world, and have reported at

>> least one that hasn't been addressed yet, I'm not seeing the problem that

>> you describe. FWIW, here's a slightly edited version of your patcher that

> The edited version let me reproduce the problem though. But I needed to

> stop the metros first, so I added a 0 message to stop the metros before

> starting the transport. the quantized will miss the first event (2 1 0.) on

for what its worth, I get the same behaviour as Stefan when using his patch
and am using an identical setup.
pelado

On Mon, Jun 30, 2008 at 10:04 AM, Stefan Tiedje 
wrote:

> Chris Muir schrieb:
>
>> While I have seen problems with the new timing world, and have reported at
>> least one that hasn't been addressed yet, I'm not seeing the problem that
>> you describe. FWIW, here's a slightly edited version of your patcher that
>> made it easier for me to test:
>>
>
> The edited version let me reproduce the problem though. But I needed to
> stop the metros first, so I added a 0 message to stop the metros before
> starting the transport. the quantized will miss the first event (2 1 0.) on
> my Powerbook (PPC, 10.4.11, 5.0.3)
>
>
>
>

I got excited when I saw this in the Max 5.0.4 bug fix list:

"timepoint: fixed potential missed triggers when using named transports, tempo changes, and/or autostart metros"

But alas, I am still seeing the behavior I reported in this thread.

Was that timepoint fix supposed to fix this problem? I looked into it a little more and it seems that metros using autostart/autostarttime/quantize will start at the autostarttime + the quantize time. In other words [metro 4n @autostart 1 @autostarttime 2.1.0 @quantize 64n] will start at 2.1.30 and then continue to bang at .30 ticks after the beat. If I specify the autostarttime it should start at that time, right?

I got in the habit of not using quantize for this sort of thing, so I can live with this behavior. But it's very counter-intuitive and bound to confuse other Max users. I'm also bothered by the fact that not everyone seems to experience this behavior (see Chris Muir's reply above), so I don't feel confident patches made on one computer will work the same way on another computer.

I got excited when I saw this in the Max 5.0.4 bug fix list:
"timepoint: fixed potential missed triggers when using named transports, tempo changes, and/or autostart metros"

Was that timepoint fix supposed to fix this problem? I looked into it a little more and it seems that metros using autostart/autostarttime/quantize will start at the autostarttime + the quantize time. In other words [metro 4n @autostart 1 @autostarttime 2.1.0 @quantize 64n] will start at 2.1.30 and then continue to bang at .30 ticks after the beat. If I specify the autostarttime it should start at that time, right? 

> Was that timepoint fix supposed to fix this problem?

[BUG] quantized metro misses first beat