<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini <span dir="ltr"><<a href="mailto:tito.01beta@gmail.com" target="_blank">tito.01beta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis wrote:<br>
> The innovation is defining an API and protocol based on 3 concepts:<br>
><br>
>     tempo synchronization<br>
<br>
</span>an integral to get the position with the new bpm<br></blockquote><div><br></div><div>across a network? with multiple tempo masters?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>     beat alignment<br>
<br>
ask to live coders<br>
<br>
>     phase alignment<br>
<br>
related to beat alignment<br></blockquote><div><br></div><div>sometimes there's magic that comes from bringing things together even if they are well known before hand. <br><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Whatever you've done in incudine, it doesn't define an actual tempo map<br>
> that can and will be shared among applications, which was always the<br>
> sticking point for JACK to be able to do this. It isn't hard to define such<br>
<br>
</span>You always think in JACK. I'm talking about an independent, public and<br>
possibly standard protocol; if you know the recipe, you write what you<br>
want. The implementation in JACK, a library from Ableton, etc, is a<br>
welcome side effect.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I want the freedom to sync a little device in assembly. One time,<br>
without the necessity to check the updates of the "protocol" on the AL<br>
web page.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You (not only Paul) are being much too defensive; perhaps I'm writing<br>
on the wrong list.<br></blockquote><div><br></div><div>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.<br></div><div> <br></div></div></div></div>