There's already an UGen implementation, so this can be used from Haskell 
via scsynth.

https://github.com/byulparan/LinkUGen/

demo:
https://www.youtube.com/watch?v=A_4OC4C7Ptk&feature=youtu.be

On 18-09-2016 12:01, Miguel Negrão wrote:
>    I think that issue has more to do with a lack of an established
> independent standard, like someone mentioned already. Without a
> standard, their implementation *is* the standard, and that is why you
> want to contribute changes back, because otherwise if you make a change
> that breaks the public interface, you become incompatible with everyone
> else. If there was a standard and a community process for moving the
> standard forward, then they not accepting changes back would not be an
> issue.
>    Open source is about being able to see and change the code, there is
> no obligation of developers accepting changes from other developers,
> that part is related with community (or lack of) and each community is
> free to setup their own rules for that.
>    But your point is important, open source projects if they are
> interested in this protocol they probably would be wise to make sure
> there was an independent standard at some point, in order not be
> dependent on Ableton. But I suspect the commercial companies will have
> much more to say about that than the small open source communities...
>
> On 17-09-2016 22:05, Alex McLean wrote:
>> One thing you can't do is contribute changes back to the project, they
>> won't accept them unless you assign them the copyright of your change
>> (so they can sell it to others under their proprietary license). So it
>> is shared under an open source license, and *looks* like a free/open
>> source project, but actually isn't one until it's forked. It could be
>> that the GPLv2 is being used here as a firewall to protect commercial
>> interests, rather than in line with the principles of software freedom
>> that gave rise to the license.
>>
>> On 16 September 2016 at 17:14, Miguel Negrão
>> <miguel.negrao-li...@friendlyvirus.org> wrote:
>>> Is the issue that you want an implementation that is BSD licensed
>>> instead of LGPL in order to use in proprietary software ? Because if you
>>> just want to use it in GPL licensed software, then you have no
>>> restrictions, you can use their implementation, change it, rewrite it,
>>> do whatever you want, as long as you don't change the license, that is
>>> keep using GPLv2.
>>>
>>> Best,
>>> Miguel Negrão
>>>
>>> On 16-09-2016 17:07, Spencer Russell wrote:
>>>> I think the fully legal clean-room path would be for someone to
>>>> reverse-engineer the code and write the spec, and then other people
>>>> (who haven't seen the code) to write implementations.
>>>>
>>>> Or maybe Ableton just hasn’t gotten around to documenting the spec
>>>> and will eventually. But given the strongly-worded branding
>>>> guidelines in the repo I’m guessing they want to maintain a certain
>>>> amount of control.
>>>>
>>>> -s
>>>>
>>>>> On Sep 16, 2016, at 11:31 AM, Tom Murphy <amin...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> This is a good point -- there's still no legal impediment, right,
>>>>> to making interoperable implementations? I.e. if the spec is the
>>>>> implementation, and the implementation is open-source, then
>>>>> effectively we can create other implementations of the protocol,
>>>>> just maybe requiring more reverse-engineering?
>>>>>
>>>>> So we don't need to wait for them to allow us to, just wait for
>>>>> them to make it easy for us?
>>>>>
>>>>> Tom
>>>>>
>>>>> On Fri, Sep 16, 2016 at 3:48 PM, Spencer Russell
>>>>> <s...@media.mit.edu> wrote:
>>>>>
>>>>>> It’s also worth noting that they haven’t really opened the
>>>>>> protocol, they open-sourced their implementation of it, with an
>>>>>> option to pay for a license if you want to use it in proprietary
>>>>>> software. Definitely a step in the right direction, and exciting,
>>>>>> but I’m hoping at some point there’s actually an open spec for
>>>>>> the protocol so there can be interoperable implementations.
>>>>>>
>>>>>> -s
>>>>>>
>>>>>>
>>>>>>> On Sep 16, 2016, at 9:51 AM, Ogborn, David
>>>>>>> <ogbo...@mcmaster.ca> wrote:
>>>>>>>
>>>>>>> EspGrid already does this and has been used and tested for
>>>>>>> years
>>>>>> (although continues to develop of course)!
>>>>>>> http://d0kt0r0.github.io/EspGrid/
>>>>>>>
>>>>>>> -D
>>>>>>>
>>>>>>> ________________________________________ From:
>>>>>>> haskell-art@group.lurk.org [haskell-art@group.lurk.org] on
>>>>>>> behalf
>>>>>> of Tom Murphy [amin...@gmail.com]
>>>>>>> Sent: Friday, September 16, 2016 9:46 AM To:
>>>>>>> haskell-art@group.lurk.org Subject: Re: [haskell art] Ableton
>>>>>>> link
>>>>>>>
>>>>>>> Agreed, this could be very cool. Promises to be a common
>>>>>>> language for timing, where participants can use different
>>>>>>> applications, enter and
>>>>>> leave
>>>>>>> at any time, make tempo changes...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 14, 2016 at 3:56 PM, Alex McLean <a...@slab.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ableton link have open sourced their sync protocol:
>>>>>>>> https://ableton.github.io/link/
>>>>>>>>
>>>>>>>> It would be wonderful to have a haskell implementation!
>>>>>>>>
>>>>>>>> alex
>>>>>>>>
>>>>>>>> -- blog: http://slab.org/ music: http://yaxu.org/ crowdfund:
>>>>>>>> http://www.pledgemusic.com/projects/spicule/
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Read the whole topic here: Haskell Art:
>>>>>>>> http://lurk.org/r/topic/29NxvfURM9xUEdjdub36Ws
>>>>>>>>
>>>>>>>> To leave Haskell Art, email haskell-art@group.lurk.org with
>>>>>>>> the
>>>>>> following
>>>>>>>> email subject: unsubscribe
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Read the whole topic here: Haskell Art:
>>>>>>> http://lurk.org/r/topic/7l2ZF7lVp3JFlNsiKMrMox
>>>>>>>
>>>>>>> To leave Haskell Art, email haskell-art@group.lurk.org with
>>>>>>> the
>>>>>> following email subject: unsubscribe
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Read the whole topic here: Haskell Art:
>>>>>>> http://lurk.org/r/topic/7IXTuUgQWEDVBlyAitdFaN
>>>>>>>
>>>>>>> To leave Haskell Art, email haskell-art@group.lurk.org with
>>>>>>> the
>>>>>> following email subject: unsubscribe
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Read the whole topic here: Haskell Art:
>>>>>> http://lurk.org/r/topic/2iefHFFxvki17setSeu28Q
>>>>>>
>>>>>> To leave Haskell Art, email haskell-art@group.lurk.org with the
>>>>>> following email subject: unsubscribe
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Read the whole topic here: Haskell Art:
>>>>> http://lurk.org/r/topic/5Va4hqdqe12yjDhk4kiLmC
>>>>>
>>>>> To leave Haskell Art, email haskell-art@group.lurk.org with the
>>>>> following email subject: unsubscribe
>>>>
>>>>
>>>
>>>
>>> --
>>> Miguel Negrão
>>> http://www.friendlyvirus.org/miguelnegrao
>>>
>>> --
>>>
>>> Read the whole topic here: Haskell Art:
>>> http://lurk.org/r/topic/6QnKaxnlxrPNSCgNcJrD4O
>>>
>>> To leave Haskell Art, email haskell-art@group.lurk.org with the following 
>>> email subject: unsubscribe
>>
>>
>>
>
>


-- 
Miguel Negrão
http://www.friendlyvirus.org/miguelnegrao

-- 

Read the whole topic here: Haskell Art:
http://lurk.org/r/topic/121fJT72lAY8NfME1zQhb8

To leave Haskell Art, email haskell-art@group.lurk.org with the following email 
subject: unsubscribe

Reply via email to