probably due to inaccuracies in the max scheduler… try an audio rate timing method to get more accurate timing if it is necessary.

In your patch try using ‘sel 0′ instead ‘sel 3′.

flim –

i tried your patch and the max scheduler must have ‘lost’ a millisecond somewhere on the clocker side. when this happens, the patch doesnt reach 2000 (it reaches 1999) and then the number continues to rise out of control!! may i suggest revising the timing mechanism (more below) or using a [>] object rather than querying just one single number

in max, data rate processes are not very reliable in terms of timing. the max scheduler queues up the processing for each max object and executes each one individually. timing using max objects can easily lose sync with ‘real’ time or even other max objects that should supposedly be synced to the same time.. say two equivalent metro’s maybe.

msp (~) objects work as audio rate signal processes rather than using the max scheduler, and are much more precise. i dont remember the difference in resolution exactly, but its far superior. they offer a much more stable and accurate platform to base timing systems on.

a [metro 100] could be replaced with a [phasor~ 10] using something like the [edge~] object to make a bang periodically every cycle, much the same way metro does.

the method using msp based objects has more accurate timing due to the way that it wont lose sync the same way that an object running on the max scheduler will do.