20 Jun
2005
20 Jun
'05
4:49 p.m.
On Mon, Jun 20, 2005 at 07:34:28PM +0200, Florian Schmidt wrote:
I dont see how a shared tempo map could be useful for these complex situations,
unless you are arguing for multiple shared tempo maps, which actually is
not much more complicated to design than a single map (although more
confusing for app devs)?
Usage of the tempo map by an app would be optional of course, so a
"simple" map in Jack would not preclude use of other sharing mechanisms.
Surely having each app separately calculating its own musical positions
is a recipe for disaster, ie lack of solid sync?
you can't
do tempo-map based transport without sharing the tempo map.
nobody has suggested a way to do this yet. please feel free.
Here i would like to chime in :) I think the mapping of BBT to frames
and the other way around isn't something that jack should be concerned
about. IMHO jack should only provide transport based on frame numbers.
Everything else, like different apps trying to agree with other apps
which frame corresponds to which BBT should really be handled by a
different mechanism.
The reason for this opinion of mine is that musical time is simply too
complex to be handled by one general mechanism. Think of different apps
using different meters, etc.. Or even a single app using different
meters on different tracks syncing to another app with yet another
meter. IMHO the notion of BBT/tempo/etc. should be local to
apps and if needed
be shared via another lib (which, if it finally settled down and became
quasi standard could again become part of jack).
Yes it should ultimately go in Jack, imo, as there doesnt seem to be any
reason against.
(No doubt i have overlooked several important details!)
go Florian!!
--
Tim Orford