Metro quantisation triggers note slightly off.
Hi everyone, I am building a sequencer in M4L and I have a fundamental problem. I can not get the metro right. All the notes are slightly off for less than a 1/128n. They are a bit delayed. This is even if the @quantize attribute on the metro is 1. Any ideas why this could be happening?
Hi, Max 4 Live automatically syncs all transport objects to the live instance. So if you start the transport (click play) in Live you can get the beats from Live in sync. https://docs.cycling74.com/max8/vignettes/live_timing
So you can just use the metro with 8n and start the transportation in Ableton Live. (note this patch only works as described within a m4l patch)
If you are looking to make a sequencer have a look at live.step. If it doesn't directly work for your project it might give you some ideas.
Hi Casper! Thank you for your reply but I am afraid that I am interested in something slightly different. I know that all transport objects get in sync with ableton but I cannot get the quantisation right. With the patch I have attached you are supposed to get notes perfectly quantised on ableton's grid, but I am not. Metro indeed triggers with the right time intervals but the notes have a tiny offset like they are slightly delayed. I also need the metro to have variable intervals but every time I change the time quantisation is going way off. It looks like a bug to me.
It looks like a bug in your patch ;-)
The 'quantize' message must go to the left inlet of metro.
Hi Broc! Thank you ! I tried your patch but I still have the same issue. This screenshot shows the offset I am getting. I can't tell how much off it is since there are no values on the time axis when you are full zoom.
The gray note is where the metro should trigger
Try using metro to trigger transport output.
It works for me with accuracy below 1 ms.
Thanks Broc, I appreciate it but this patch has the same accuracy with the one posted above. The problem lies in the metro object, which seems unable to perfectly quantise with live. For what I am building, I 'd really like to have perfect synchronisation. I have seen other M4L sequencers being in sync with live so I am curious how other people do it and why the "@quantize" attribute in metro is not working as documented.
Here is a another solution without metro in particular for M4L devices.
Yeah, that is a good one! I 've tried it but unfortunatly has the same latency!
If you have system latency, it is probably allways of same length
and tempo independent.
In such case I would use plugsync~ sample count outlet,
and offset it for needed amount, then calculate beat length
in samples for modulo to bang notes.
@Source audio. tried that too but can't quantize the notes properly nomatter what offset I use. Am I the only one that has this problem though?
I don't use Live at all, but latency should be possible to deal with.
I mean You have host running, it spits sample count out,
You take that, offset it forward for needed amount and generate midi notes.
Adjust till notes get recorded aligned.
If You can't manage that, than I don't know what is wrong.
Maybe Live is a wrong software to use ...
Some people report that M4Live devices behave
different in edit mode than when they are locked
Or have You set some sort of midi quantising in live track ?
I mean You have host running, it spits sample count out
Yes, but I've found that plugsync~ reports the host data (including sample count) only every 64 samples (=vector size in M4L) which at 44.1kHz corresponds to a time interval of about 1.5 ms.
in other words, sample accurate midi synchronisation is not possible. But generally I don't see why inaccuracy in the order of 1 ms would be a problem in practice. It corresponds to a 1/2048 note at 120 bpm.
I see, so it is not a real sample count.
So there is no audio rate sync option in Max4Live ?
I thought inaccuracy was not the problem, but latency
as stated in first post and it seems to be constant.
But anyway - I am not the right person to discuss Live problems...
[phasor~ 16n @lock 1] should sync with Live at audio rate
then offsetting the phasor could do as well.
but one needs to calculate latency compensation
dependent on tempo.
sample count would have been simpler