diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2013-09-17 02:14:21 -0700 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2013-09-17 02:14:21 -0700 |
commit | 844d31616bfd90cf743489897bf2ceb3b72c27e3 (patch) | |
tree | 0ba5b0ac6ad484a3e8c8c9055474234f564cd1c3 /src/TrackListModeScaleView.cpp | |
parent | 72f567f6560ad2fda9bb82ebe9abf8ad4911e67e (diff) | |
download | sekaiju-844d31616bfd90cf743489897bf2ceb3b72c27e3.tar.gz sekaiju-844d31616bfd90cf743489897bf2ceb3b72c27e3.tar.bz2 sekaiju-844d31616bfd90cf743489897bf2ceb3b72c27e3.zip |
This commit solves a remaining problem of events accidentally looping back
during recording when midi through is disabled in the binding array.
The problem is caused by the fact that the real-time events are inserted into
the tracks just at the start of the next clock period. When the next clock
period comes, those events are played back! (This also causes a delay:
since the looped notes will not play until the next clock advance!)
To solve this problem we do two things:
1. Rearrange the processing so that playback, metronome generation
et cetera are handled first in every processing period, and the real-time
input is handled afterward.
2. Now that real-time inputs are handled after playback, we can simply insert
them into the CURRENT time period. Since playback is already done
for the current time period before, they will not be played.
Referring new events into the current time period is done by subtracting
one from the clock value. Sekaiju's logic for handling time periods
is that each time period is an interval that excludes the current
time: [old_time, new_time). So when an new event is inserted at new_time,
it becomes part of the next period. By inserting an event at new_time - 1,
we make it part of the current period.
Hey, I wrote some comments in Japanese. :)
Diffstat (limited to 'src/TrackListModeScaleView.cpp')
0 files changed, 0 insertions, 0 deletions