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
>

-- 

Read the whole topic here: Haskell Art:
http://lurk.org/r/topic/1abN7vz8mBY9EPohCu468T

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

Reply via email to