Re: [LAD] aBLETON lINK

hi,

I've posted about Ableton Link a number of times now on LM and LAD but I
was never satisfactorily responded to..

Here's my post from LM https://linuxmusicians.com/viewtopic.php?f=1&t=14913
here's the same thing I posed on LAD
http://linux-audio.4202.n7.nabble.com/ableton-link-and-live-tempo-changing-td99835.html

well I hope someone sees my post this time. But anyway I'm just copying my
message from LM if anyone has opinions:

Hey rui,

I've noticed the discussions on github/LAD (the latter of which i am still
unable to post on[image: :?] ) and your PR to Link. It seems like you've
made reasonable progress with it-- can you comment on how feasible the
ideas I described in my original post are?

I am still vaguely under the impression that if a Timebase master client is
Link-capable then any transport-aware client (e.g. most LAU apps today)
would be able to follow any tempo changes described by the master and
therefore automatically have "Link support"-- from my understanding the
JACK Timebase includes transport control and BPM information (though maybe
not beat sync information like Link?). Then can't a timebase master client
be Link-obedient just in regards to BPM but operate transport independently
(since Link doesn't have transport a transport representation anyway)?

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.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Sep 21 16:15:02 2016