I've been using Max too long not to have looked in to this weird issue yet, but I'm trying to use [play~] to trigger a sample, in this case a hi-hat. I'm banging from [metro] (also from [delay]), which should send out constant bangs at exactly equal time intervals. However, listening to it it's obvious that the timing is not exact, but slightly differs from bang to bang. Why is this, and is there any better way to go about triggering samples so as to get an exactly quantized pattern rather than a slightly fluctuating one?

I've been using Max too long not to have looked in to this weird issue yet, but I'm trying to use [play~] to trigger a sample, in this case a hi-hat.  I'm banging from [metro] (also from [delay]), which should send out constant bangs at exactly equal time intervals.  However, listening to it it's obvious that the timing is not exact, but slightly differs from bang to bang.  Why is this, and is there any better way to go about triggering samples so as to get an exactly quantized pattern rather than a slightly fluctuating one?

is-metro-exact

short answer is no it is not exact, as it depends on the max scheduler

what you want is sample accurate triggering, check the replies in this thread

https://cycling74.com/forums/index.php?t=msg&goto=172079&rid=5063&S=db58cbdc419ea7e817e5def8e6fc546f&srch=audio+rate+sequencer#msg_172079

you should be able to test the inaccuracy of the timing system using a [timer] object to count the time between events - and it should show pretty clearly that theyre not perfect.

an audio rate timing system will be accurate.

the_man361 wrote on Tue, 20 October 2009 10:39

you should be able to test the inaccuracy of the timing system using a [timer] object

as shown in [p sched_test] in cpuclock.maxhelp

the_man361 wrote on Tue, 20 October 2009 10:39you should be able to test the inaccuracy of the timing system using a [timer] object

as shown in [p sched_test] in cpuclock.maxhelp


is metro exact?