[linux-audio-dev] What parts of Linux audio ....Tempo Maps

Florian Schmidt mista.tapas at gmx.net
Thu Jun 23 16:20:29 UTC 2005


On Mon, 20 Jun 2005 22:26:54 +0200
Tim Orford <tim at orford.org> wrote:

> > Now there's Apps B and C. B should be in sync with A's first track and C
> > should be in sync with A's second track.
> > 
> > Don't know if this is really overkill though. I would find it useful..
> 
> i wouldnt use it personally, but doing N is not much more work than 1.

True :) Except for the management overhead. Plus the added complexity
for application developers which would have to present a choice to the
user.

> > The idea which lingers in the back of my head is not a "tempo map" as a
> > structure which has meters/tempi for certain time ranges, but rather
> > arbitrary mapping functions which map BBT -> frames and frames -> BBT
> > (or even BBT -> time and time -> BBT and another pair od predefined
> > mappings time -> frame and frame -> time). With this scheme an app could
> > easily do linear or even nonlinear tempo changes, loops, etc..

And i surely was on crack when i wrote this. There's no efficient
interprocess function call mechanism on linux (one of the reasons jack
uses this fifo thingies to trigger execution of the clients' audio
callbacks).

> (not sure i fully understood all that.)
> Sure its nice for an app to provide a line/curve based gui for this,
> but should it be "rendered" to meter/tempo pairs before exporting? This
> would depend on how much resolution you need for a smooth change.

Yeah, since directly calling the mapping functions is out of question,
the mappings need to be "rendered". Hmm, then all the nice properties go
out of the window.

> I
> guess that even as little as a 1/32th would be fine, as long as tempo information
> wasnt used somewhere as the basis of say pitch adjustment, but dont really know.
> As the resolution went up it would become more impractical to share the
> map in rendered form, but on the other hand, multiple apps rendering the
> same line/bezier might be a bit wasteful. Anyone know how much
> resolution is needed?
> 
> possible average case: 32 * 200bars => 6400 meter/tempo pairs
> 
> i assume you dont see a need to share the actual curve description
> between apps, for the purposes of, eg, editing?

No, as one app provides it and another uses it. The editing has to be done in the app that provides the tempo mapping..

> > ticks_per_beat, but depending on how this calculation is done, different
> > apps might come to different results. But this might be a non issue as
> > the BBT info is updated by the timebase master in each process cycle.
> 
> ah, thats a very good point. (But still i cant help think that separately
> calculated positions will not be completely trusted even if they are in fact
> identical:-). And for example, an editor at v high zoom wont be interested
> in the current process cycle. Plus, a tempo change can happen mid cycle.)

This remark i don't understand..

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/



More information about the Linux-audio-dev mailing list