I tested your patch and got the same results you must be seeing: In a 1 bar clip in 4/4, with a perfect 16th note on the downbeat of each bar, the 4th note @ piano roll position 1.4 always reads as 119ms, while the rest read 120ms.

What's funny is that depending on the length of the clip and the length of the notes in question, different positional values will have the error, but it's always the same position for that set. I can delete all the other notes in the test clip, and just leave the 16th note @1.4 and it will be off by 1ms every time... and ditto for the problematic position with 32nd notes or dotted 16ths.

I rebuilt your patch using mostly different objects, and got the exact same results relative to what borax is telling me.

Very interesting, but I have no idea what causing this. Sorry.

I'm on Live 11.0.1 and Max 8.1.9

Thanks for testing it and clarifying. I appreciate your trying.

I too built an alternative patch, but measuring in transport ticks as I am trying to build an accurate polyrhythm sequencer triggered by notes lengths, but the ticks count was out by up to 5 ticks. Causing the sequencer to occasionally jump to the next beat at higher note intervals.

Not sure if its Max or Live causing the problem, or if there is another way to measure more accurately.

Is there anyone from @cycling74 that would shed some light on this? Thanks.

I am on the latest versions of Live and Max. Scheduler in Overdrive and Audio Interrupt checked.

The problem could be that time data in clips are beats as float numbers while the metro interval is ms or ticks as integer.

That's a great point, BROC. That would explain the absolute consistency of the 1ms difference I was seeing.

Thanks BROC. I'll rework the patch along those lines to see if it is a fix.