On Mon, 4 Jan 2010, Arnold Krille wrote:
> Last time I looked (two years back sadly), even hydrogen did the bpm changes
> wrong. On a new bpm it would recalculate the position from the beginning of
> playtime with the new bpm. Which meant missing beats...
While Hydrogen's transport code is... erm... not good -- I
don't think I ever got a missed beat from a tempo change.
> It would be pretty cool if jack had functions to do the time<->beat
> calculation but sadly most jack developers seem to think that tempo and tempo-
> maps (not even live) do not belong into jack...
I'm still thinking about the whole "tempo map" proposal
(which doesn't make much sense for a "live" client)...
...but time<->beat calculations have proven to be so
error-prone, I think that some helper functions in Jack to
do the calculations would be a Good Thing. I have a C++
class that does this[1]. It's for Composite's internal
transport -- but it's largely inspired Jack's transport.
This class is intended to be used like a local variable.
TransportPosition pos = get_current_position();
jack_nframes_t end = pos.frame + nframes;
pos.ceil(TransportPosition::TICK);
while( pos.frame < end ) {
// Do operations on this tick.
++pos; // advance to next tick.
}
I imagine an equivalent C API would look like:
jack_position_t pos;
jack_transport_query(client, &pos);
jack_nframes_t end = pos.frame + nframes;
assert(pos.valid & JackPositionBBT);
jack_position_ceil(&pos, JackPositionTick);
while( pos.frame < end ) {
// Do operations on this tick.
jack_position_advance(&pos, JackPositionTick); // advance to next tick.
}
-gabriel
[1] http://gitorious.org/composite/composite/blobs/9b5b20671ad187bd3f6733838447070def793ce8/src/Tritium/Tritium/TransportPosition.hpp
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
