20 Jun
2005
20 Jun
'05
5:28 p.m.
On Mon, 20 Jun 2005 20:49:36 +0200
Tim Orford <tim(a)orford.org> wrote:
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??)
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)? 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/