8 Jun
2010
8 Jun
'10
1:14 a.m.
On Wednesday 02 June 2010 01:25:28 Gabriel M. Beddingfield wrote:
With respect to real-time temop changing, I've
given this subject a
lot of thought and code while working on InConcert.[1] Here's my
thoughts...
Thanks Gabriel... I was actually leaning towards one of the other
options, so that's definitely food for thought :)
But everything you wrote makes perfect sense, and I'm starting to think
that the "floating reference" approach is indeed the one that makes most
sense for klick to implement.
As soon as both audio-frame-based clients and BBT-based clients are
present and syncing to JACK transport, there's simply no way for the
timebase master to keep both in sync. And I doubt that users would
expect clients like Ardour to do on-the-fly timestretching when the
transport changes tempo - although it would be great if it could...
So the question is, if you change the tempo in
the middle of a
song, at which point does that change take effect?
Simple answer: immediately. Furthermore, the issues you mention all have to do
with /seeking/.
This only make sense in a "live" situation if the host sequencer has
special support for it anyway. For a simple implementation, you can
mostly ignore seeking.
Here's a few different ways to approach it:
1. Floating Reference/Epoch: This is the first case you
mentioned. When the tempo changes, you recalculate
your BBT/frame reference point. Frame 0 is no longer
1:1.0... so you will (as a special case) reset the
timeline whenever someone relocates to 0.
Is relocating to zero really different enough from seeking to other
positions to make it a special case? At the very least, the timeline
would also need to be reset when seeking would otherwise result in a
negative frame or bar number.
The only case I can think of where it would be advantageous to avoid
resetting the timeline is when seeking relative to the current position
(whatever that means in terms of the UI used), but I'm not sure if
that's really a convincing argument.
Cheers,
Dominic