[LAU] Klick oddity

[Gabriel M. Beddingfield]

Hi Dominic,

On Wed, 2 Jun 2010, Dominic Sacré wrote:

> You're right, klick does not act as a JACK transport timebase master
> when run in interactive mode...

First, klick is really sweet.  My favorite feature is -t/-T.

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.

Complex answer:  Read on.

> If you change the tempo, but keep both the current frame and BBT, you
> allow frame and BBT to effectively go out of sync (going back to the
> first bar, you'd not end up at frame 0 anymore).
> On the other hand, if you recalculate the position based on the
> beginning of the timeline, either the frame or the BBT position has to
> change. And either way, some clients (probably those syncing to BBT)
> will be forced to jump to a different position.

Yes, in fact when I first announced the concept of InConcert, I think
the title was something like "Abusing the transport for live tempo
sync."  You can't do everything, so you have to choose one, and just
be clear about which one you are choosing.

ATM, the primary use-case is with sequencers.  Most of the
audio-frame-based trackers (ardour, audacity, qtractor) are
disregarding BBT info for audio, anyway.  The only way those guys
could support this sort of real-time flexibility is if they allow
on-the-fly time stretch and stuff like that... and I don't know of any
that do.

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.

    2. Recorded Timeline / Epoch Stack:  You keep track of
       all the tempo changes... and always base your current
       calculations off the most recent change.  If someone
       seeks backward... you "time travel" to the BBT, frame,
       and (optionally) tempo that occurred at that time.
       This is similar to the way that Ableton will record a
       live session.

    3. Frame-based timeline:  There is a fixed "master"
       timeline that is friendly with the frame-based trackers.
       If you ever do a live-tempo change, you deviate from
       this map.  However, if you ever seek, you return to
       this map.  (I can't imagine this to be very useful,
       but maybe something along these lines could play along
       with programs like ardour.)

I recommend #1 since it's simple to implement, is the most flexible
WRT time-signature changes, and simple for users to understand.

Hope this helps,
Gabriel

[1] http://www.teuton.org/~gabriel/InConcert/