Yes, it's a basic limitation. Each M4L device (audio or midi) introduces latency depending on Live's audio buffer. Unfortunately this behavior is not mentioned in the official documentation.

Strictly speaking, it's not jitter but predictable latency which remains constant unless the audio buffer of Live is changed.

There is noticeable jitter on my machine , worse at higher buffers 512 is unusable for drums, 128 passable. This is in addition to uncompensated latency. Do others have this jitter?

In my experience and based on timing tests, processing midi through M4L devices introduces no jitter provided that the devices communicate via standard routings of Live, ie. no extra routings with send/receive objects.

Maybe you should explain your situation in more detail. Are you referring to midi input when playing live or just playback from clips or sequencers? What happens if you record the processed notes into a clip? Are the timing variations visible in piano roll?

If I play a hihat sample on sixteenths at 120bpm, and put a max midi device containing just the standard two objects, midiin to midiout, before the sampler, and record the audio output to a resampling track, at a buffer of 512, a jitter of around 8ms is introduced. About half the hats are on the money and the rest are 8ms early. The same pattern of jitter is also apparent if I remove the sampler and record the midi output to another track.

I can't imagine that jitter is introduced by an empty max midi device. What happens if you remove the device and record the played sixteenths directly to another track?

They are all bang on the money , zero jitter.

Just did a quick test, playing a midi clip with 16th notes through an empty max midi effect and recording to another track. It turns out that all recorded notes appear with perfect timing even at highest resolution 1/16384 (~0.1msec} as shown in the picture.

Are you sure that this is midi jitter? I did following test - Miditrack 1 holds max monosequencer which plays16th notes. Miditrack 2 set to receive midi notes from Miditrack 1. After recording midi output from max monosequencer device I can't observe any jitter in recorded Miditrack 2 - check attached screenshot of recorded 16th. If you talk about audio buffers than this jitter most likely is introduced on interpreting midi notes by audio device and probably has nothing to do with max midi processing.

heh, we are nearly in sync :)

Broc, what buffer size did you use? Can you try a big buffer 2048 or 1024 and see what happens? I get jitter of 20ms or more at these buffer sizes

Gjvti , its not the audio device. The audio device is sample accurate at all buffer sizes. The timing errors are introduced when midi enters max for live, at larger buffer sizes.

It would be helpful if anyone can replicate this so i know its not my setup.

I'm running an Imac core 2 duo. Latest versions of live and max.

I've repeated my test with buffer 2048 and get the same perfect timing as before.

This is on Mac OS 10.5.8, Live 8.4, Max 5.1.9

I can't believe that other versions behave differently since midi jitter *inside* a DAW would be a fundamental flaw.

I'm on Mac 2.4ghz core 2 duo OS 10.7.5 Max 6.1.1 Live 9.0.2

CPU showed 1% when I did the same test as you, at buffer 2048, empty song, just a max midi device, recording 16ths into another track. The jitter is pretty big as you can see. Bypassing the max device banishes the jitter completely.

Even more confusingly, this is intermittent. I just closed all applications and restarted my machine and the problem has vanished. After I have been working for a while, the problem re appears, even if I create a new empty song. I have no idea what causes it to re-appear. I think this problem also occurred with Live 8 and Max 5.

It could be a memory (RAM) problem, ie. system overload caused by swapping. Look at the Activity Monitor how your system memory is used, in particular number of page outs.

OK, Ive had Live running normally for a couple of days, and the problem has come back again, same as previously, 30ms jitter at 2048. I don't really understand what page outs or swapping are. Here is a screenshot of the Activity monitor while this problem is occurring.

The number of page outs > 0 means that at some point (since last system restart) there wasn't enough RAM to load required data and thus some "old" data had to be saved/swapped to disc. The screenshot shows free RAM but apparently swapping has occurred in the past. You could do a system restart (setting page outs to 0) and observe if and when the number increases.

Of course system overload by swapping is just a theory. For proper investigation of the issue it would be helpful to have a simple reproducible scenario.

I don't understand why a lack of memory previously could leadto timing errors. I can't find a specific way to reproduce the problem. It just seems to start after a while of continual use.