On 09/21/2016 11:24 AM, Perry Nguyen wrote:
Though after reading your post to LAD a couple times over it seems like
there is possibly overlooked but important incongruity between BPM and
"linear/real-time".. and perhaps that limits the ability of word-clock
time designators like JACK from seamlessly following BPM? If that is the
case it is still unclear to me what the specific technical details of
that incongruity are.
(continuing my own babbling...:))
read this?
http://github.com/jackaudio/jackaudio.github.com/wiki/TransportLimitations
(JACK Transport Limitations)
ok. now from the top of my head.
a. jack-transport/timebase (JT) is a centralized master/slave model,
including its API approach; corollaries follows: all JT clients start
and stop on demand and at the same time; netjack clients might drift
apart, unless they implement some sort of PLL/DLL device (anyway, this
assumes one of the participants is master); time reference is absolute
frame position, constant sample-rate (frames/second), starting from a
designated master application, linear (tape-like) timeline model (a
song, session or project as a whole length continuous composition or
arrangement).
b. ableton-link (AL) is a distributed metronome facility and API; any AL
client may or not be playing its thing on any given time, but when they
play, they *should* start and sync (internally on their own premises)
on beat boundaries on their own best-fit strategy model; time reference
is tempo (BPM; beats/minute); tempo changes are broadcasted (well, dang
truth is multicasted), may be initiated by any participant, then each
other participant may react accordingly (or not) on their own chance,
next cycle or phase, whichever fits best their own designed playback
model--this is why, AL is more suited for loop-based contraptions that
straight linear-tape model ones.
you can map AL to JT (timebase) if you will, but it's one master's job
to do it--make the time calculations according to its own master, static
tempo-map.
hth.
cheers
--
rncbc aka. Rui Nuno Capela