jtay

I'm using a seq object to record MIDI loops. I've found that when I record a loop and listen to it played back, the loop tends to rush. I checked this by putting a MIDI Quantizer on the output end. (I'm sending the MIDI data over rewire to Cubase which is hosting my plugins. I put the MIDI Quantizer MIDI effect on the MIDI track there.) I would record the loop, making sure that the quantizer didn't move any notes to the wrong beat, and then listen to the loop play back a few times. Eventually the quantizer started reacting and shifting notes around. The loop would always start on time, since it was triggered by the metro object, but by the end of each loop--8 bars long, 4/4 time, 105bpm--it would be off by about a 1/16th note value, and there would be a brief pause of silence at the end of each loop.

All that being said, is there a more accurate way of recording MIDI loops besides the seq object? The MIDI tutorial says there are many ways to sequence MIDI, but doesn't describe any of them.

accurate-midi-sequencing

i don´t use [seq] for two reasons. first it seems not possible to change the start of a midi sequence, and second it is not easy to handle the data and especially the delta time format when doing further editing. therefore my way basically goes along [borax] and [coll].

there is a patch attached with the current version of a midi tracker optimized for loops with variable start end. there is a random note generator included as well to have an easy start.

- the data is saved in a [coll] as "time, note velocity duration marked-flag". don't get irritated, the marked-flag is for using a note-editor which allows to select and mark notes for manipulation, it has no use inside this patch.

- most important is lovely [borax] as it works very reliable and delivers key information like "duration" and "active voices"

- chords are saved a somehow special and "wrong" way: as you can't have stored the same timepoint twice as index, the timepoint is always checked for its availability. if it is not available the starting time of that note is shifted for 1ms.

- when recording overdubs for loops it's often annoying when a held note is interrupted and set off by an already recorded note. i decided to delete the old timepoint for a note, if it tries to happen while that note is recorded again.

- for changing tempo you always have to recalculate all index data (and duration values probably) multiplying a factor. just do a dump, unpack/pack and a [zl join] and this happens really quick.

- the data is saved in a [coll] as "time, note velocity duration marked-flag". don't get irritated, the marked-flag is for using a note-editor which allows to select and mark notes for manipulation, it has no use inside this patch. 

- chords are saved a somehow special and "wrong" way: as you can't have stored the same timepoint twice as index, the timepoint is always checked for its availability. if it is not available the starting time of that note is shifted for 1ms. 

- when recording overdubs for loops it's often annoying when a held note is interrupted and set off by an already recorded note. i decided to delete the old timepoint for a note, if it tries to happen while that note is recorded again. 

accurate MIDI sequencing