andrea agostini

I am experiencing some weird behaviour from the timer object - see the patch below. Everything is fine when I click the green bang, but if I click the red bang (which moves the computation to the scheduler thread) the timer object always returns 0. I think we can call it a bug...

Cheers,
aa
OSX 10.6.7, Max 5.1.8, overdrive on


timer-object-issue

It can be repaired with a defer. A bug or a scheduler anomaly. Someone actually might be able to explain this behavior.

I don't think that this is a bug. Uzi does all its work in one scheduler frame. I'm pretty sure no scheduler time passes between the rightmost bang and the leftmost bang in your [b 3] object.

I see what you mean, but my point is - scheduler time _should pass for Uzi as well.

It looks like timer doesn't check the actual system time (which is what I expected), but the time elapsed between the beginnings of the scheduler events triggering the bangs in its inlets. While this makes sense in most situations, in extreme cases (like my example) it leads to unconsistent results, as in fact there is only one, very long event.

Have a look at this version as well: if I interpret it correctly, as long as the yellow delay is greater than Max's scheduler interval two distinct events are scheduled and timer works fine. But if it's

Uzi's whole deal is that it does everything as fast as possible: within one scheduler tick. It breaks the normal Max event rules this way. If you need time to pass you need to use something like metro, instead.

Hum, I'm not sure what you're trying to achieve here Andrea, but perhaps 

Hum, I'm not sure what you're trying to achieve here Andrea, but perhaps cpuclock is what you're looking for?


What I posted is just the simplest example I could find of a strange behavior I have remarked in timer. In real life, the time I'm trying to measure comes from a (hopefully) more useful computation than Uzi 10000000 - I'm trying to compare the efficiencies of several versions of an external.

The reason of my post is not finding a different solution for the problem (indeed, cpuclock works perfect for this), but signaling what looks like a design issue to me...

timer object issue