Redefine getTickPosition() to return the actual tick position (without any lookahead).
A forum user reported [1] that MIDI notes are *sounding* at the right time,
but being *recorded* about 1/16th late. Sebastian Moors (smoors) said [2]
that he isolated to SVN rev 210, where lead-lag was introduced. In
that commit, the value of m_nPatternTickPosition was adjusted to
include a lookahead factor. This allowed notes with positive lead and
positive humanize (i.e. before the beat) to be correctly scheduled.
However, realtime notes were then recorded *with* the leadlag, putting
notes 5 ticks + 2000 frames late (typ. 8-11 ticks). It was typically
not noticeable with quantize on -- but with quantize off, it was
always present. To correct this, I rewrote getTickPosition() to
recalculate the tick... rather than use the global
m_nPatternTickPosition (which is integral to updateNoteQueue's
scheduling).
This commit has one (minor) issue: If you turn on quantize and you
give a note that is way out in front of the beat (at the edge of the
quantize window), you will probably hear the note twice: Once for the
realtime event, and once for the note that was recorded in the
pattern. I believe that this only happens when the realtime note and
the scheduled (quantized) note differ by the amount of lookahead.
[1] http://www.hydrogen-music.org/forum/?action=show_thread&thread=882&fid=5&page=1
[2] e-mail to hydrogen-devel@…, 08SEP2008.
