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

On Mon, Jun 20, 2005 at 09:28:53PM +0200, Florian Schmidt wrote:
> App A is a sequencer having two tracks at two different meters (i'm
> thinking polyrythmic here, so the meters/tempi might be related (just to
> make a point about the usefulness of this)).
>
> 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.

> Other features i would like to see would be smoothely (or non smoothely
> changing) tempi, etc..
>
> 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..

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

> Again, no idea, if this is at all doable (fast enough
> ipc mechanism??)

showing my ignorance as a lowly gui man here, but doesnt Jack use shm anyway?

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

cheers

-- 
Tim Orford