On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini <tito.01beta@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.