Inaccurate midi notes timing
Dec 23 2010 | 1:55 pm
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.
- Dec 23 2010 | 7:33 pmI 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.
- Dec 24 2010 | 4:25 amThanks 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?
- Dec 24 2010 | 11:48 amNo, 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.
- Dec 25 2010 | 12:56 pmThanks 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.
- Dec 26 2010 | 8:04 pmNow 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?
- Dec 26 2010 | 10:53 pmApparently 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.
- Dec 27 2010 | 3:03 pmThe 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!
- Dec 27 2010 | 5:57 pmThe 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.
- Dec 29 2010 | 2:18 amThanks. I will try Max4Live later. For now I just sent an email to cycling74 support to see if they have any solutions.
