maybe i am missing something but i experience a strange bug with detonate recently.
i am playing 2 or more tracks of data into several tracks and/or channels of a receiving [detonate], then export a midi file from detonate using the "write" message and it ends up with a midifile where some of the tracks seem to have a minor shift in time, as if some of the tracks would have been recoding the incoming data a bit slower than other detonate tracks.
also, i am unsure about the "write" message in detonate in max v4, because it is not correctly documented.
firstly, as opposed to the ref pdf it allows three types of export formats, text, midi, and binary – and i would love it to export midi only – but while getting through that fileout dialog. the docs say it would do only midi. :)
then i dont fully understand how to use the arguments to "write" which are mentioned on the reference.
"write 1 0 patch.mid" should write s file with speed in absolute values of ms, but it does not seem to work right.
is there a special trick to record data to detonate and save it to a proper midifile?
it is pretty confusing when you record something in realtime, and while you listen to it all is ok, but later when looking at the data in detonate or nuendo, the last note of track 5 come 351 ms too early and the music is all fupped up.
I’ve once experimented with detonate and found that it exports midi files with resolution of only 96ppq. At 120 bpm this corresponds to a time resolution of 500/96=~5ms. So on export, converting delta times from ms to ppq will introduce substantial accumulative rounding errors.
To avoid this problem, detonate should either export with higher ppq resolution (eg. 480) or provide an option to use ppq-based timing internally.