> 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?
> (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
> 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
> rncbc aka. Rui Nuno Capela
It seems that the lack of interest in adding similar functionality to JACK
has opened up a gap in the "market".
Is there any specific reason that JACK *cannot* be used to enable a
similar looping mechanism via the transport control or in parallel?
Boost Hardware Ltd
Linux-audio-dev mailing list