inaccurate timing of a metro synced to Live's transport
Hi,
I’ve been working on a step sequencer in max4live and noticed that the output of a metro synced to Live’s transport is quite inaccurate. Midi note triggered by the metro are delayed by a number of samples (10-20) compared to midi notes coming from a Live clip. I could live with it if the delay was constant but, there is aslo a substantial jitter.
I though that metro synced to Live’s transport was supposed to be "tick accurate".
This kind of jitter makes max4live kind of useless for designing step sequencers, since it introduces random phasing problems
I’ve attached a max4live patch as well as an audio file demonstrating the issue. In the audio file, I have recorded outputs from two instances of Impulse. One driven by a midi clip the other by a metro synced to the beat. Both instances trigger a sample with an impulse. In the audio file (if you zoom in) you can see that the impulse with higher amplitude (which was triggered by metro) is delayed by a "random" number of samples in relation to the other impulse (which always happens exactly on the beat).
Has anyone encountered a similar problem?
I’d really appreciate some comments from the devs on this one.
best
Adrian
btw. I’m running Max 6.0.5 and Live 8.3
patch used to trigger the notes below:
"I think that 1ms is about the resolution of the Max event world"
Qoute from this thread (Chris Muir).
Hi broc,
yes, I know there are limits to the timing resolution of messages in Max (but only as interpreted by MSP objects: evens in the scheduler are actually time stamped with 64bit accuracy) and it is linked to the signal vector size (if overdrive is on), but I though that there was some mechanism built into the transport system, which would make things tightly synced with Live’s midi timing (so accuracy down to 1 tick).
anyway, this discovery sucks!
best
yeah you have discovered the limitations of m4l / live.
there are a few things going on, such as the always on delay incurred going in and out of an m4l device that is also cumulative, the fact that live’s pdc does not compensate, the fact that in live, max is fixed overdrive on, audio in interupt on, sig vector 64.
i’m not sure that this is fixed in 9 / 6.1 either. probably still a project for the devs for the future. quite a huge impossible task though i imagine. only concept of a shared audio graph would fix? i do not know entirely what i am talking about but that is the impression i get. it has always been that way.
> yeah you have discovered the limitations of m4l / live.
But the limits of event timing resolution are imposed by max, not m4l / live.
(for example, supercollider provides event resolution in microseconds).
@pid
a question that coms to mind: is this information stated anywhere in the docs?
@broc
this is a limitation of most real time sound processing softwares. Some exceptions are for example Chuck~ and LuaAV (they are "strongly timed"). I haven’t used supercollider that much but I believe it also suffers from the it. The problem is not the actual timing of messages, but at what time intervals these messages can affect the audio graph. But still, there are workarounds. Like delaying everything by a vector and making the audio objects aware of the time stamps (which can be as accurate as the clock of the cpu) of the messages. This solution is used in gbr.ola~ from IRCAMs FTMGabor packed, or in vline~ in PD). By the way, I am wondering why nobody has programmed a vline~ like external for Max yet (question to devs: is it even possible?).
So my point is: I thought that developers have come up with some workaround for messages synchronised to transport. Wishful thinking :)