Ian Dicke

In my commercial M4L devices, I create a clock by running a metro @interval 1 ticks, @quantize 1 ticks. This has worked very well (better sync with Live's transport than using phasor~ or gen~), but now the timing is misaligned with the Max 8.5.1 update.

When I remove the quantization attribute, it works OK-ish, but I really want to maintain the very predicable results I was previously receiving with the quantization on.

In my commercial M4L devices, I create a clock by running a metro @interval 1 ticks, @quantize 1 ticks. This has worked very well (better sync with Live's transport than using phasor~ or gen~), but now the timing is misaligned with the Max 8.5.1 update.


When I remove the quantization attribute, it works OK-ish, but I really want to maintain the very predicable results I was previously receiving with the quantization on.


In my commercial M4L devices, I create a clock by running a metro @interval 1 ticks, @quantize 1 ticks. 

metro-quantization-bug-in-max-8-5-1

Update: Actually, I think the problem has something to do with using Plugsync~ to turn my metro on and off. Used to work fine, now it doesn't. But I can get around that by using the API to notify metro when Live's transport is running. I know I could also use @active 1 with metro directly too.

Metro Quantization Bug in Max 8.5.1