[LAU] Klick oddity

[Dominic Sacré]

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...
> 
> > 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.

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...
 
> 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