Inaccurate midi notes timing
First of all, sorry for my English. I’m not a native speaker and it’s difficult for me to describe my problem I met clearly in the title. But I think a simple patch may help to explain:
----------begin_max5_patcher---------- 938.3oc4Y1kbaBCEE9Y6UACSez0C5JP.cEz8PmNcH1JNzXK4BJMIMS16EIgS HNBPNfURreQNRQ15vmt2i9gGlNw+B9czReuu48CuISdX5jIpljMLot9D+MY2 sXcVopa9L5s7K9s+L8+RPuSnZtjt1CC6ZNeopwpN90vfcMtMSr3pb1peUPWH zCIBkLOXlWXfpDKKks38y5uB6lM4r0TgZng5FujyDrrMT0P7c55+RE4Kx7e9 qvuQr+2Q2j39sT8.6eQFak+LOe+mFK4OaY9+Tc.AyCjs93zoxhYCiMWSu2.X vo8CFcYT57nt.Sva.LgsAlblPxkW+wXBpMzxxrUzWQJDNxDoR5fTPbpjQPjr DCJRQFyPHTajxEgNxzJjIjf6BIQ5LoTMSHe1SqZKZIlXfLPWAKQfNshjdRFs rIeY9k7hMYByAMA8iFLRGtDDzcTS7Xxlw1doE7rMaw0lvBper.w3iUtz6aDS 10TFWPq9YiqxDXlvCXAdz1uHTOQM3wzq4x07L0pS5+vINNwlbb5xKFSvmwNN PT+n4LzwAH8ikyXGGH1B7bt33jXBPfEGc3ytiSaD41hbA0DT5Z2MXMTfTRij pSHnTJ3aMvDT2mbB0jI3SMlT8jxKVZhJcY+BuHRIL5yJUZ8.k+wDQrvPIDfF FJsZ3hFSC25qePcpx2+cyfP8Soyvcyfr3F9Ni2MiEWy24xlYDzMa4dewTtEo +q3SugFB5DyQVTjwJ2xKDlt779oBBoicf3wO0J0tKIduHol+godMpPUvWsZs osCh6OsSGJAA6J6dAsCxKdDcXnhBdKVKVrdDBodHIQNz305kqU8wecNa+WAk 54Q19K4UI+lhE6FkZuUumehVRKE4rLQNm0nOxkmZzoqxWtjxZ9ZSpV0eKuZZ qVCsL4cHRBYijPNSRxiK1KlRcJkj2YVuRRdO.tTSwVL0Iu5FWN0EaCmHtkSI VnIL3TMoFt9l6jWzuCm6v1j1ozj63DwBIE51YNarv+vonCjQxcmUcp4jDYIn +PVNPkhP1.O2lIt2xssnI2NiZCl.2hIvlLQ4qO4iFlvuoHeTnJlGGCOUanYo 1nVbvGO.lLD.FgiGK.tWv03XdTOAii0xTqcUsgNcGbDTaMMGe0hHGA0B05iP ZpVYsgp1jigZSBNNpENFQB3iEasYyD32lmp9MT.DXWkgJUq1J1AdViZ4AQg5 K5L9oZigZ68f1Itcmi1jH41Cqgs4JRBc6xjg1jAiGfjpp73z+uTbIgE -----------end_max5_patcher-----------
The patch is simple. After you press SPACE, the [metro] will start to generate 3 midi notes (whose length are 32n) for every 16th note. Then they go to [midiformat] and are finally recored by the [seq]. After you press SPACE again, the metro will stop and you can save the midi sequence stored in [seq] to a midi file. Because the simplicity of this patch, if I open the midi file in a daw like ableton live, I expect that all notes recorded are aligned to grid perfectly.
However, the result is shown in the image below. You can see that the timing of some notes are "off".
I wonder if I made some fundamental mistakes in Max setup because the patch itself is so simple. I’m using the latest Max/MSP (5.1.7) on Mac OS 10.5.8. The CPU and memory usage is always very low.
By the way, the overdrive option is already turned on.
I can reproduce the behavior here. It’s due to the low timing resolution (96 ticks per quarter note) of the exported midi file. So the quantization error of 1 tick corresponds to 1/384th note. But in general this shouldn’t have any audible effect.
Thanks for your reply. But for a more complex patch, [seq] will gives unacceptable result (shown in the screenshot, it’s an one-bar loop). I wonder if I misuse [seq], do I need to give it tempo information to record correctly?
If I use [tempo] instead of [metro], will it become better?
No, I don’t think that metro or tempo will make a difference.
The general problem with [seq] is that it doesn’t handle musical timing (i.e. tempo, beats and ticks) but instead stores the timing of notes in milliseconds. When generating notes the times in milliseconds are calculated from the actual tempo. Afterwards any information about the musical timing (i.e. tempo and beat structure) is lost.
Consequently, on midi file export there is no tempo information available. Hence a file with default tempo 120bpm is generated and the placement of notes is adjusted to this tempo. In other words, if the original tempo is different from 120bpm, the placement of notes after export will NOT correspond to the original beat structure.
Nevertheless, if the notes are generated at tempo 135 and the exported file is played back at tempo 120, the notes will actually play at original tempo 135.
Thanks a lot! Now when I import the midi file to live I tell live the actual bpm and everything seems to work OK.
I need to post edit these midi files so have notes aligned to grid helps a lot.
Now this drives me crazy. As I mentioned, if I import the midi file into live and tell it the bpm, everything works ok. But actually every bar is slightly off, and for a long enough record, the entire loop shift for a 16th note after a dozens of bars (shown below). Any suggestion?
Apparently the drift is caused by accumulation of rounding errors.
So I’d suggest to record only a few bars and do the looping with Live on playback.
The problem is what I want to record is not a simple loop (I use loop to make the point more clear) but a string of long, non-repeating miid notes. Do you think if I use [seq~] instead of [seq] will make things better?
Anyway, thanks for your input again!
The internal timing of [seq~] is more accurate, but it can’t export midi files..
Personally I’m using Max4Live. It allows to generate midi clips with musical timing (beats as floats). And if needed the clips can also be exported from Live as midi files.
Thanks. I will try Max4Live later. For now I just sent an email to cycling74 support to see if they have any solutions.