If Tidal is similar to sclang patterns in that each sound is played by a 
separate synth then probably this ugen is not very usefull. For that 
probably a haskell native wrapper is better suited.

On 18-09-2016 13:42, Tom Murphy wrote:
> This looks awesome and the code is really clean. The only issue I'd see for
> use with e.g. Tidal is I don't see anywhere where the "phase
> synchronization" happens, so if e.g. Live is playing in some odd time
> signature I don't think Tidal could follow along.
>
> On Sun, Sep 18, 2016 at 12:52 PM, Miguel Negrão <
> miguel.negrao-li...@friendlyvirus.org> wrote:
>
>> 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
>>
>


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

-- 

Read the whole topic here: Haskell Art:
http://lurk.org/r/topic/54xROVS7zW7MSCbW8LQz00

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

Reply via email to