aBLETON lINK

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

aBLETON lINK

Tito Latini
What is the content of the network packets ?

Regardless, I'll ignore software with that technologogy.
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Paul Davis
why?

On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <[hidden email]> wrote:
What is the content of the network packets ?

Regardless, I'll ignore software with that technologogy.
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Patrick Shirkey

> why?
>
> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <[hidden email]>
> wrote:
>
>> What is the content of the network packets ?
>>
>> Regardless, I'll ignore software with that technologogy.
>

The OP seems to be suggesting that whoever has access to the data captured
by Ableton Link or the potential backdoor that link *might* enable would
use it for nefarious purposes.

If seriously worried about such issues then it's probably not a good idea
to use gmail, cellphones, walk around in most populated areas of the
world, participate in modern society, etc...

I suggest to not enable an external network connection if using software
that has this *potential* security threat enabled *and* it is a cause for
concern.

+/- 0.00002 btc

--
Patrick Shirkey
Boost Hardware Ltd

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Robin Gareus
On 09/19/2016 11:56 PM, Patrick Shirkey wrote:

>
>> why?
>>
>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <[hidden email]>
>> wrote:
>>
>>> What is the content of the network packets ?
>>>
>>> Regardless, I'll ignore software with that technologogy.
>>
>
> The OP seems to be suggesting that whoever has access to the data captured
> by Ableton Link or the potential backdoor that link *might* enable would
> use it for nefarious purposes.

Ableton link is used to synchronize software and devices on a *LAN*.
It basically broadcasts BPM and song-position to the *local* network.

Link does not allow to synchronize devices on a WAN.

The complete source code is free (GPLv2) you can read it, no strings
attached.

ciao,
robin
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Patrick Shirkey

> On 09/19/2016 11:56 PM, Patrick Shirkey wrote:
>>
>>> why?
>>>
>>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <[hidden email]>
>>> wrote:
>>>
>>>> What is the content of the network packets ?
>>>>
>>>> Regardless, I'll ignore software with that technologogy.
>>>
>>
>> The OP seems to be suggesting that whoever has access to the data
>> captured
>> by Ableton Link or the potential backdoor that link *might* enable would
>> use it for nefarious purposes.
>
> Ableton link is used to synchronize software and devices on a *LAN*.
> It basically broadcasts BPM and song-position to the *local* network.
>

Because netjack isn't good enough or cross platform enough or LGPL enough
or adopted enough?

> Link does not allow to synchronize devices on a WAN.
>
> The complete source code is free (GPLv2) you can read it, no strings
> attached.
>

Be careful, apparently you might get brainwashed ;-)


--
Patrick Shirkey
Boost Hardware Ltd

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Ralf Mardorf-2
On Tue, 20 Sep 2016 07:03:58 +0200, Patrick Shirkey wrote:
>Because netjack isn't good enough or cross platform enough or LGPL
>enough or adopted enough?  

Hi,

yes, it's not cross platform enough.

Audiobus and other iPad apps provide Ableton Link. Jack doesn't run on
the iPad anymore, so there unlikely ever will be netjack available. It
would be nice to be able to sync a tablet PC with the Linux DAW by wifi.
AFAIK Linux based tablet PCs are still not real-time capable. I have no
idea how good sync by wifi works, maybe MIDI by cable still is the
better way to go.

Regards,
Ralf
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Tito Latini
In reply to this post by Robin Gareus
On Tue, Sep 20, 2016 at 12:04:53AM +0200, Robin Gareus wrote:

> On 09/19/2016 11:56 PM, Patrick Shirkey wrote:
> >
> >> why?
> >>
> >> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <[hidden email]>
> >> wrote:
> >>
> >>> What is the content of the network packets ?
> >>>
> >>> Regardless, I'll ignore software with that technologogy.
> >>
> >
> > The OP seems to be suggesting that whoever has access to the data captured
> > by Ableton Link or the potential backdoor that link *might* enable would
> > use it for nefarious purposes.
>
> Ableton link is used to synchronize software and devices on a *LAN*.
> It basically broadcasts BPM and song-position to the *local* network.
>
> Link does not allow to synchronize devices on a WAN.
>
> The complete source code is free (GPLv2) you can read it, no strings
> attached.

I know how to read the code; done before to send the first message.

My question is a provocation for the sleepers.

The synchronization with other devices through the network to share
bpm, time, positions, strings, etc, is not an innovation. Many persons
(me too) use private protocols written ad hoc from scratch to sync the
devices within a room. Non standard protocols, useful for limitated
circumstances.

A standard protocol is better (i.e. NTC, Network Time Code).

I can discover the current protocol used by AL (thanks for the
additional work) and use my network interface to dialog, for example,
with Reason. If AL fixes some problems or decides to change the
protocol, Reason is updated but my code fail. It is necessary
other work to learn the changes.

With a public protocol, there are two or three revisions, then there
is the possibility to get a standard. It is simplest and professional.
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Robin Gareus
In reply to this post by Patrick Shirkey
On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
>
> Because netjack isn't good enough

correct.

jack can have a single timebase master and likewise netjack has a single
net-master.

Ableton-Link is decentralized: Multiple performers can interact with
each other on an equal level (no master/slave semantics).

It's not groundbreaking tech. Laptop orchestras and the likes have used
similar techniques since a while, but all prior-art that I know is ad-hoc.

As far as I know this is the only protocol concerning *musical-time*
that's spec'ed out, has a cross-platform reference implementation and
potential to find its way into hardware.

Feel free to criticize the protocol on a technical level or hunt for
bugs in the implementation ... or simply ignore it silently.

ciao,
robin
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Patrick Shirkey

> On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
>>
>> Because netjack isn't good enough
>
> correct.
>
> jack can have a single timebase master and likewise netjack has a single
> net-master.
>
> Ableton-Link is decentralized: Multiple performers can interact with
> each other on an equal level (no master/slave semantics).
>
> It's not groundbreaking tech. Laptop orchestras and the likes have used
> similar techniques since a while, but all prior-art that I know is ad-hoc.
>
> As far as I know this is the only protocol concerning *musical-time*
> that's spec'ed out, has a cross-platform reference implementation and
> potential to find its way into hardware.
>
> Feel free to criticize the protocol on a technical level or hunt for
> bugs in the implementation ... or simply ignore it silently.
>

So then the next question would be is there any reason NOT to integrate it
directly into JACK?







--
Patrick Shirkey
Boost Hardware Ltd

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Daniel Swärd
On Tue, 2016-09-20 at 13:40 +0200, Patrick Shirkey wrote:
> > Feel free to criticize the protocol on a technical level or hunt
> for bugs in the implementation ... or simply ignore it silently.
> >
>
> So then the next question would be is there any reason NOT to
> integrate it directly into JACK?

That would be _very_ interesting. Immediately making all (well, more or
less) Linux audio apps syncable would be a big win.

        /Daniel
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Robin Gareus
In reply to this post by Patrick Shirkey
On 09/20/2016 01:40 PM, Patrick Shirkey wrote:

>
>> On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
>>>
>>> Because netjack isn't good enough
>>
>> correct.
>>
>> jack can have a single timebase master and likewise netjack has a single
>> net-master.
>>
>> Ableton-Link is decentralized: Multiple performers can interact with
>> each other on an equal level (no master/slave semantics).
>>
>> It's not groundbreaking tech. Laptop orchestras and the likes have used
>> similar techniques since a while, but all prior-art that I know is ad-hoc.
>>
>> As far as I know this is the only protocol concerning *musical-time*
>> that's spec'ed out, has a cross-platform reference implementation and
>> potential to find its way into hardware.
>>
>> Feel free to criticize the protocol on a technical level or hunt for
>> bugs in the implementation ... or simply ignore it silently.
>>
>
> So then the next question would be is there any reason NOT to integrate it
> directly into JACK?
>

There's an existing feature request already: [1]


JACK cannot be slaved to anything. jackd is always master, so there's a
conceptual conflict.

Closest concept is jack-timebase master [2]. A client can provide
musical-time to jack and thereby to all jack clients that support jack
transport.

So yes, there are some reasons to not *directly* integrate it, but like
existing jack tools [3] (jack_lsp, jack_connect, jack_transport,...) it
could be included with jack one way or another. Seamless integration is
possible. It just needs someone to do the work.

Rui already has a working standalone prototype (no timebase support yet,
but it's a good start).

There are also some technical details to be sorted out: e.g. the current
Link reference implementation requires C++11, jack-tools are C89... but
those are details.


Cheers!
robin


[1] https://github.com/jackaudio/jack2/issues/231
[2] http://jackaudio.org/files/docs/html/group__TransportControl.html
[3] https://github.com/jackaudio/tools

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Ronald Stewart
people still use abelton?
geez with NI tractor ns8 I can't imagine or phathom needing a slow antiquated midi based performance piece LOL

Ron Stewart

On Tue, Sep 20, 2016 at 8:25 AM, Robin Gareus <[hidden email]> wrote:
On 09/20/2016 01:40 PM, Patrick Shirkey wrote:
>
>> On 09/20/2016 07:03 AM, Patrick Shirkey wrote:
>>>
>>> Because netjack isn't good enough
>>
>> correct.
>>
>> jack can have a single timebase master and likewise netjack has a single
>> net-master.
>>
>> Ableton-Link is decentralized: Multiple performers can interact with
>> each other on an equal level (no master/slave semantics).
>>
>> It's not groundbreaking tech. Laptop orchestras and the likes have used
>> similar techniques since a while, but all prior-art that I know is ad-hoc.
>>
>> As far as I know this is the only protocol concerning *musical-time*
>> that's spec'ed out, has a cross-platform reference implementation and
>> potential to find its way into hardware.
>>
>> Feel free to criticize the protocol on a technical level or hunt for
>> bugs in the implementation ... or simply ignore it silently.
>>
>
> So then the next question would be is there any reason NOT to integrate it
> directly into JACK?
>

There's an existing feature request already: [1]


JACK cannot be slaved to anything. jackd is always master, so there's a
conceptual conflict.

Closest concept is jack-timebase master [2]. A client can provide
musical-time to jack and thereby to all jack clients that support jack
transport.

So yes, there are some reasons to not *directly* integrate it, but like
existing jack tools [3] (jack_lsp, jack_connect, jack_transport,...) it
could be included with jack one way or another. Seamless integration is
possible. It just needs someone to do the work.

Rui already has a working standalone prototype (no timebase support yet,
but it's a good start).

There are also some technical details to be sorted out: e.g. the current
Link reference implementation requires C++11, jack-tools are C89... but
those are details.


Cheers!
robin


[1] https://github.com/jackaudio/jack2/issues/231
[2] http://jackaudio.org/files/docs/html/group__TransportControl.html
[3] https://github.com/jackaudio/tools

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Paul Davis
In reply to this post by Patrick Shirkey
The people who designedand wrote Link are entirely familiar with JACK (if only because I taught them about it).

I too was a bit disappointed when Link was announced (last Novemeber) because it seemed redundant given JACK transport. But once they released the SDK for iOS and later the code for all platforms, it became clear that the Link team has come up with something quite different, extremely useful and really rather clever. Even just their clear identification of different kinds of musical time sync is a huge contribution for those of us who think about such things.

Ableton is actually full of quite a lot of software developers who are into open source. I don't know why there needs to be the level of disdain and skepticism for the company itself just because, like most other s/w development companies, they use a proprietary model. Their documentation for their Push2 surface is an exemplary example of how any company (even an open source one like Monome) should and could document a hardware device and how to interact with it. Likewise, their release of the Link SDK as GPL code for all platforms is a remarkably strong statement from a company whose core products are all released under proprietary licenses.


On Tue, Sep 20, 2016 at 1:03 AM, Patrick Shirkey <[hidden email]> wrote:

> On 09/19/2016 11:56 PM, Patrick Shirkey wrote:
>>
>>> why?
>>>
>>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <[hidden email]>
>>> wrote:
>>>
>>>> What is the content of the network packets ?
>>>>
>>>> Regardless, I'll ignore software with that technologogy.
>>>
>>
>> The OP seems to be suggesting that whoever has access to the data
>> captured
>> by Ableton Link or the potential backdoor that link *might* enable would
>> use it for nefarious purposes.
>
> Ableton link is used to synchronize software and devices on a *LAN*.
> It basically broadcasts BPM and song-position to the *local* network.
>

Because netjack isn't good enough or cross platform enough or LGPL enough
or adopted enough?

> Link does not allow to synchronize devices on a WAN.
>
> The complete source code is free (GPLv2) you can read it, no strings
> attached.
>

Be careful, apparently you might get brainwashed ;-)


--
Patrick Shirkey
Boost Hardware Ltd

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Patrick Shirkey

> The people who designedand wrote Link are entirely familiar with JACK (if
> only because I taught them about it).
>

We know that. So are the people at Google who used JACK as the basic
design reference for their attempt at low latency audio.

> I too was a bit disappointed when Link was announced (last Novemeber)
> because it seemed redundant given JACK transport. But once they released
> the SDK for iOS and later the code for all platforms, it became clear that
> the Link team has come up with something quite different, extremely useful
> and really rather clever. Even just their clear identification of
> different
> kinds of musical time sync is a huge contribution for those of us who
> think
> about such things.
>
> Ableton is actually full of quite a lot of software developers who are
> into
> open source. I don't know why there needs to be the level of disdain and
> skepticism for the company itself just because, like most other s/w
> development companies, they use a proprietary model.

Maybe it's because they explicitly stated that AL would *never* run on
Linux and then attempted to explain their justification for that decision
with a essay and speech at LAC (but that's just a guess).

> Their documentation
> for their Push2 surface is an exemplary example of how any company (even
> an
> open source one like Monome) should and could document a hardware device
> and how to interact with it. Likewise, their release of the Link SDK as
> GPL
> code for all platforms is a remarkably strong statement from a company
> whose core products are all released under proprietary licenses.
>

These are steps in the "left" direction but it's not hard to imagine their
marketing department getting veto over any actual attempts at integrating
with existing Open Source projects like ex. JACK simply because of the
branding opportunities of releasing software like Link as their own
standard.

Jack => Link .... hmmm, no similarity there.

IIUC, even with all your expert advice AL does not support JACK directly.
which seems a shame seeing as JACK is a "spec'ed out, cross-platform
reference implementation" that has *already* found its way into hardware.




>
> On Tue, Sep 20, 2016 at 1:03 AM, Patrick Shirkey
> <[hidden email]
>> wrote:
>
>>
>> > On 09/19/2016 11:56 PM, Patrick Shirkey wrote:
>> >>
>> >>> why?
>> >>>
>> >>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <[hidden email]>
>> >>> wrote:
>> >>>
>> >>>> What is the content of the network packets ?
>> >>>>
>> >>>> Regardless, I'll ignore software with that technologogy.
>> >>>
>> >>
>> >> The OP seems to be suggesting that whoever has access to the data
>> >> captured
>> >> by Ableton Link or the potential backdoor that link *might* enable
>> would
>> >> use it for nefarious purposes.
>> >
>> > Ableton link is used to synchronize software and devices on a *LAN*.
>> > It basically broadcasts BPM and song-position to the *local* network.
>> >
>>
>> Because netjack isn't good enough or cross platform enough or LGPL
>> enough
>> or adopted enough?
>>
>> > Link does not allow to synchronize devices on a WAN.
>> >
>> > The complete source code is free (GPLv2) you can read it, no strings
>> > attached.
>> >
>>
>> Be careful, apparently you might get brainwashed ;-)
>>
>>
>> --
>> Patrick Shirkey
>> Boost Hardware Ltd
>>
>> _______________________________________________
>> Linux-audio-dev mailing list
>> [hidden email]
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>>
>


--
Patrick Shirkey
Boost Hardware Ltd

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Paul Davis


On Tue, Sep 20, 2016 at 9:46 AM, Patrick Shirkey <[hidden email]> wrote:

> The people who designedand wrote Link are entirely familiar with JACK (if
> only because I taught them about it).
>

We know that. So are the people at Google who used JACK as the basic
design reference for their attempt at low latency audio.

Except .. they didn't.
 

Maybe it's because they explicitly stated that AL would *never* run on
Linux and then attempted to explain their justification for that decision
with a essay and speech at LAC (but that's just a guess).

Not a very good guess, IMO.
 

Jack => Link .... hmmm, no similarity there.

I don't think you've read enough about Link. It does stuff that JACK transport cannot do. It is designed around concepts that JACK doesn't have.

Conflating JACK (transport) and Link is a mistake. I made it myself. I would suggest not doing that.
 

IIUC, even with all your expert advice AL does not support JACK directly.
which seems a shame seeing as JACK is a "spec'ed out, cross-platform
reference implementation" that has *already* found its way into hardware.

I didn't give ableton any "expert advice". I was a guest professor 6 years ago who happened to be one of the people who taught some of the people who were later recruited by Ableton and ended up developing Link.

And again, JACK does *not* do what Link does (nor vice versa).
 

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Rui Nuno Capela
In reply to this post by Robin Gareus
On 09/20/2016 01:25 PM, Robin Gareus wrote:
>
> Rui already has a working standalone prototype (no timebase support yet,
> but it's a good start).
>

jftr. there's these posted upstream:
   https://github.com/Ableton/link/pull/5
   https://github.com/Ableton/link/pull/6

however, for the time being, this is only about adding example
applications (linkhut, qlinkhut, etc.) with jack audio support, as in
alternative to portaudio on linux.

again for the time being, it has nothing to do with jack-timebase, at
least yet, and for x sake, it probably won't do anything about
jack-transport, which i believe is not applicable nor substitute

i see each, jack-transport and ableton-link, as orthogonal in function
and purpose. iow., an application either adopts jack-transport *or/and*
ableton-link protocol (possibly through a jack-timebase proxy) to sync
its "play time".

afaiu. jack-tranpsort is about absolute sample/frame real-time
positioning; otoh. ableton-link is about relative tempo, beat and/or
phase (within a bar or measure)  musical-time ie. it's better described
as a shared *metronome* over the LAN (wether it's wired or wireless: low
level is multicast udp/ip, so that it works on the local net segment
switches but never across routers). iow. ableton-link is *not* a
wall/word-clock for keeping media streams in sync. and it doesn't do
WAN, so you can keep your tinfoil in the closet :).

point is, applications using the ableton-link facility have to implement
special, dedicated sync patterns, which are not bearable to a linear
real-timeline, so to speak. it is best suited, or recommended, for
syncing loopers on musical BBT and tempo (BPM) units, abstract time
boundaries if i may, not to concrete linear/real-time stream players.

on the practical side of thoughts, i mean, i'd say to scrap any
jack-transport implementation on superlooper or seq24, for example. make
those sync to ableton-link instead. hydrogen would have a great boost in
usability too, i'm sure. though, old plain linear timeline based DAWs,
eg. ardour, (or sequencers for that matter) qtractor, muse(score),
rosegarden, etc. would be better still set to jack-transport as
master/slave as usual, maybe set ableton-link tempo and beat/bar phases
according to their rolling playback state, that is as long as to
function as timebase masters.

as a final note, and conclusive perhaps, ableton-link integration is an
application/client option, not quite on the JACK server/service side if one.

just my 2eur.
--
rncbc aka. Rui Nuno Capela
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Paul Davis


On Tue, Sep 20, 2016 at 10:03 AM, Rui Nuno Capela <[hidden email]> wrote:
 [... ]
just my 2eur.

with real world exchange rates based on expertise and wisdom, i'd say that's about US$1M's worth of insight.
 

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Louigi Verona
Thanks, Paul and Rui, very interesting info.

On Tue, Sep 20, 2016 at 5:08 PM, Paul Davis <[hidden email]> wrote:


On Tue, Sep 20, 2016 at 10:03 AM, Rui Nuno Capela <[hidden email]> wrote:
 [... ]
just my 2eur.

with real world exchange rates based on expertise and wisdom, i'd say that's about US$1M's worth of insight.
 

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev




--

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Rui Nuno Capela
In reply to this post by Paul Davis
On 09/20/2016 04:08 PM, Paul Davis wrote:

>
> On Tue, Sep 20, 2016 at 10:03 AM, Rui Nuno Capela <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>      [... ]
>     just my 2eur.
>
>
> with real world exchange rates based on expertise and wisdom, i'd say
> that's about US$1M's worth of insight.
>

thanks Paul, yw
wait, smtm!

jk.

cheers
--
rncbc aka. Rui Nuno Capela
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: aBLETON lINK

Tito Latini
Thanks Patrick.
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
123