Re: [LAD] aBLETON lINK

[Thomas Brand]

On Tue, September 20, 2016 17:03, Rui Nuno Capela wrote:
> 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.
>

Rui, thanks for this concise summary for the layz! It sounds like
something that's missing in Linux Audio land.

However looked from a distance, it's funny to see how things change. It
was for some people common practice to smile at ableton-like loop
facilities because it was looked at as something less favourable to
non-looped "real" music. Just to now explain why this new product from
ableton makes sense, after being sucked in at grandiose marketing events.
It's certainly well if that product is GPLed, independent of it being for
totally egoistic reasons of that company.
Greetings
Thomas


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA Sequencer timestamp on event without scheduling

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 20/09/16 15:26, Clemens Ladisch wrote:
>> In other words: any application that does care about timestamps will
>> never see your timestamps.
>
> Yes. And that's why my first question.
>
> How can we implement this timestamp feature in ALSA with the current
> implementation?

Not at all.

> If it is not possible, how feasible is for us to add this feature?

The ALSA sequencer API is an interface between multiple drivers and
applications.  Adding a feature to the interface will not have any
measurable effect because no other application will use it.

The time of an event is the time at which it is actually delivered.
If you want to be compatible with most other applications, you have
to deliver the events at the desired time.


Regards,
Clemens
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Tito Latini]

Thanks Patrick.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Rui Nuno Capela]

On 09/20/2016 04:08 PM, Paul Davis wrote:
>
> On Tue, Sep 20, 2016 at 10:03 AM, Rui Nuno Capela  > 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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Louigi Verona]

Thanks, Paul and Rui, very interesting info.

On Tue, Sep 20, 2016 at 5:08 PM, Paul Davis 
wrote:

>
>
> On Tue, Sep 20, 2016 at 10:03 AM, Rui Nuno Capela  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
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>


-- 
Louigi Verona
http://www.louigiverona.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Paul Davis]

On Tue, Sep 20, 2016 at 10:03 AM, Rui Nuno Capela  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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Rui Nuno Capela]

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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Paul Davis]

On Tue, Sep 20, 2016 at 9:46 AM, Patrick Shirkey  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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA Sequencer timestamp on event without scheduling

[Felipe Ferreri Tonello]

Hi Clemens,

On 20/09/16 15:26, Clemens Ladisch wrote:
> Felipe Ferreri Tonello wrote:
>> On 19/09/16 13:27, Clemens Ladisch wrote:
>>> And applications that care about the time of received events
>>> tell the sequencer to overwrite the timestamp with the actual delivery
>>> time anyway.
>>
>> Applications only need to care about the timestamp field for that event,
>> it doesn't matter who set it (the ALSA Seq scheduler or other client, in
>> this case the BLE driver).
> 
> When the receiving port has timestamping mode enabled, the sequencer
> will overwrite any timestamp that the event had.
> 
> When the receiving port does not have timestamping mode enabled, the
> application will not read the timestamp, because there is no guarantee
> that it is set.
> 
> In other words: any application that does care about timestamps will
> never see your timestamps.

Yes. And that's why my first question.

How can we implement this timestamp feature in ALSA with the current
implementation? If it is not possible, how feasible is for us to add
this feature? Any suggestions?

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] 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
> > wrote:
>
>>
>> > On 09/19/2016 11:56 PM, Patrick Shirkey wrote:
>> >>
>> >>> why?
>> >>>
>> >>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini 
>> >>> 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
>> Linux-audio-dev@lists.linuxaudio.org
>> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>>
>


-- 
Patrick Shirkey
Boost Hardware Ltd

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ALSA Sequencer timestamp on event without scheduling

[Clemens Ladisch]

Felipe Ferreri Tonello wrote:
> On 19/09/16 13:27, Clemens Ladisch wrote:
>> And applications that care about the time of received events
>> tell the sequencer to overwrite the timestamp with the actual delivery
>> time anyway.
>
> Applications only need to care about the timestamp field for that event,
> it doesn't matter who set it (the ALSA Seq scheduler or other client, in
> this case the BLE driver).

When the receiving port has timestamping mode enabled, the sequencer
will overwrite any timestamp that the event had.

When the receiving port does not have timestamping mode enabled, the
application will not read the timestamp, because there is no guarantee
that it is set.

In other words: any application that does care about timestamps will
never see your timestamps.


Regards,
Clemens
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Paul Davis]

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  wrote:

>
> > On 09/19/2016 11:56 PM, Patrick Shirkey wrote:
> >>
> >>> why?
> >>>
> >>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini 
> >>> 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
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] 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  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
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] 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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Robin Gareus]

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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Tito Latini]

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 
> >> 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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] aBLETON lINK

[Ralf Mardorf]

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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev