On Mon, 20 Jun 2005 20:49:36 +0200 Tim Orford <[EMAIL PROTECTED]> wrote:
> > 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. > > 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)? I was thinking along the lines of having multiple tempo maps for this. 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.. 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.. These mapping functions can be "exported" by apps for other apps to use. (in the above example, A would export two mapping functions, one for each track. In the Apps B and C the user would then choose which of A's mappings to use). Again, no idea, if this is at all doable (fast enough ipc mechanism??) > 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? Yeah, i agree the mapping must be deterministic. I'm not sure it is atm (the jack_position_t struct carries ticks_per_beat and beats_per_minute info, but not frames_per_tick. It does have frame_rate though so ticks_per_beat could be derived from frame_rate, beats_per_minute and 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. Arr, this whole thing is complex and i might be full of sh*t :) Flo -- Palimm Palimm! http://affenbande.org/~tapas/
