[LAD] aBLETON lINK

[Paul Davis]

On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini <tito.01beta at gmail.com> wrote:

> On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis wrote:
> > The innovation is defining an API and protocol based on 3 concepts:
> >
> >     tempo synchronization
>
> an integral to get the position with the new bpm
>

across a network? with multiple tempo masters?


>
> >     beat alignment
>
> ask to live coders
>
> >     phase alignment
>
> related to beat alignment
>

sometimes there's magic that comes from bringing things together even if
they are well known before hand.

i am aware of no attempt to define any kind of of protocol, API or SDK that
does what Link does. the fact that a few people on the edges of computer
music production have done some of them individually before doesn't really
change that.


>
> > Whatever you've done in incudine, it doesn't define an actual tempo map
> > that can and will be shared among applications, which was always the
> > sticking point for JACK to be able to do this. It isn't hard to define
> such
>
> You always think in JACK. I'm talking about an independent, public and
> possibly standard protocol; if you know the recipe, you write what you
> want. The implementation in JACK, a library from Ableton, etc, is a
> welcome side effect.
>

I'm not talking about just JACK. I'm talking about how hard it is to define
a standard for a shared tempo map that people will ACTUALLY use. There is
no such thing at this point in time. If there is one, it will come from
someone/some organization who can put immediate momentum behind it, because
the adoption cost of fitting someone else's model of a tempo map into each
application is high.


>
> I want the freedom to sync a little device in assembly. One time,
> without the necessity to check the updates of the "protocol" on the AL
> web page.
>

nobody is making you do anything. you can do whatever you want. but if you
want your "little device" to sync with other people's "little devices" then
there needs to be some joint understanding of how that is going to work. AL
is an example of someone trying to do that.


>
> You (not only Paul) are being much too defensive; perhaps I'm writing
> on the wrong list.
>

you seem to have reacted quite negatively and critically of AL, apparently
because, despite its GPLv2 license, it comes from a company that
traditionally uses a proprietary development and licensing model. i don't
understand this point of view.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20160922/ba81e4e8/attachment.html>