Re: Klick oddity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux