20 Jun
2005
20 Jun
'05
6:27 p.m.
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