17 Feb
2013
17 Feb
'13
3:28 a.m.
On Saturday 16 February 2013 03:58:10 Frank Kober wrote:
I've tried to do that move from an ALSA backend to
a JACK MIDI one in
QMidiArp, and used vectors as a queue for event timings. It doesn't
support tempo changes on the fly and I even didn't think about how to
implement this. The ALSA sequencer queue has a very convenient features
A few people have mentioned tempo changes on the fly as a troublesome area.
So let me think about this:
Changing a tempo doesn't change the number of ticks. It does change the time
value (in nanoseconds) of each tick. So suppose at time x a tempo change
occurs. We let startTick = nanosToTicks(x) be our new starting tick for future
calculations according to our new tempo. nanosToTicks() is then set to use the
new tempo. So really our function could be nanosToTicks(x, tempo).
This is essentially what we do if we're playing a smf with a tempo change.
Presumably, what seems to concern people is an additional tempo adjustment
(e.g. pushing a button to slow playback to half speed). But this is just a
scale factor. Then we have nanosToTick(x, tempo, scale), which is the same
calculation above except that we multiply by scale at the end.
I don't really see the issue here. Or is everyone else talking about something
different?
--
7:8