Re: [LAU] Klick oddity

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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Jun 8 04:15:02 2010