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:
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.