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-… 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.