Re: [LAD] aBLETON lINK

[David Robillard]

On Fri, 2016-09-23 at 13:00 +0200, Patrick Shirkey wrote:
> I suppose that their marketing department has decided that Linux
> Developers/Users don't represent a big enough share of the market to
> justify committing more resources to the platform.
> 
> However JACK also runs on the other two main platforms so what is their
> rational behind completely ignoring it altogether while committing
> resources to creating a competing API?

Let me start by saying I love the idea of Jack.  IMO it is,
unquestionably, The right way to do an audio API/system, and it's
fantastic.

... however, using Jack on other platforms is a gigantic PITA.  Hell, it
is on Lignux, too, but we're just used to it.  It lacks the polish of
something that can act as The system audio API, largely because all of
that stuff (shiny device selection support, flexible handling of
changing rates, and so on) wasn't in its design priorities in the first
place, but that doesn't change the reality of things.

That's unfortunate, but one needs to have been living deep in the LAD
bubble to pretend otherwise.  We haven't even managed to make Jack the
go-to out of the box audio API on Linux distributions, to say nothing of
OSX or Windows.  Which, in terms of market relevance, does mean that
companies like Ableton have little incentive to care.  For most users,
it's just this extra thing they have to deal with that doesn't provide
much if anything for their use case.

I don't think it's particularly helpful to complain that commercial
companies don't build on our technologies, regardless of what you think
of them.  It's more useful to ask: why?

Much of it (a bit ironically) boils down to the very fact that we aren't
driven by certain forces that commercial developers are.  We can, and
do, just ignore polish, or ease of use, or features that we don't
particularly feel like bothering with, and so on.  That's the nature of
unfunded free software development, really.

That said, occasionally, there are nefarious motivations behind lack of
adoption / platform support, and so on... but not always.

Jack is not my child, though, so it's a bit more honest and revealing to
use LV2 as an example.  It's a free and open audio plugin spec, it's
powerful, it does mostly everything, and considerably more, than the
proprietary specs, and it does some things dramatically better.  Why,
then, has it not taken over as the go-to audio plugin spec for everyone?
Is it because the commercial developers are evil?  Well, maybe, a little
bit, for a few of them with a vested interest in the proprietary APIs
themselves, but really it's because LV2 is "weird", distributed in a
Linuxey modular way where you need a bunch of separate libraries to
implement it, there's no standard shiny/easy C++ bindings, nobody really
regularly does the effort to make it super integrated and easy to use on
other platforms, and other external issues like the good ol' portable
plugin UI problem make things difficult.  There's a few technical points
in there, but it really just boils down to polish, packaging,
documentation, and so on.  There's a long list of things that need to
happen there, I'm keenly aware of what most/all of them are, and I don't
blame commercial developers for not caring at the moment.

It's not their fault for not adopting it.  It's ours, it's mine, for not
presenting things on as polished a silver platter as possible, and I
accept that.  So it is with Jack.

(Interesting intersectional sidenote: I've realized lately that in order
to better establish LV2 on Windows/OSX, I need to write a native host,
which is to say, a non-JACK one.  A JACK one is weird and requires
setting up a bunch of other stuff at which point you've already lost)

It's getting better, and we're making progress, but whining that nobody
likes / cares about / uses our technology isn't going to help.  They
have reasons.  Our technology is fantastic in many ways, better than
what the proprietary people work with in several, but it's also terrible
in other ways, and those ways are considered equally, if not even more,
important by most commercial developers.  Hobbyists working on the fun
parts in their spare time don't share those priorities, but they're
priorities nonetheless.

-- 
dr


___
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 Fri, Sep 23, 2016 at 1:51 PM, Louigi Verona 
wrote:

> Paul, not to derail the conversation, but can you give us a little detail
> on what kind of problems happen in scenarios outside of the desktop
> environment? I am just curious.
>

building and installing JACK was hard.
making it work with the audio chipset was hard (no duplex mode, or
asymmetric parameters required)
RT kernels are hard, sometimes.
the command  line is obscure.
the manual page isn't (wasn't?) accurate.
which version of JACK to use.
___
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]

Paul, not to derail the conversation, but can you give us a little detail
on what kind of problems happen in scenarios outside of the desktop
environment? I am just curious.

On Fri, Sep 23, 2016 at 5:52 PM, Markus Seeber <
markus.see...@spectralbird.de> wrote:

> On 09/23/2016 05:13 PM, Paul Davis wrote:
> > The last time I was working with such a person was deeply illustrative: a
> > small technology company doing audio on raspberry pi and beagle boards.
> > Using JACK. Having an insanely hard time even getting it work. Even with
> me
> > sitting in with them. Their experience is common. Maybe even the norm. We
> > never targetted JACK for such uses (focusing on desktop scenarios).
> > Developers think it is cool, was developed on the same OS as they are
> > running their new embedded platforms - awesome! Except ... not so much.
> >
> Exactly what I have experienced. It is all well for prototypes and for
> testing out stuff,
> but when things become serious, it all falls apart and people may notice,
> that jack is not even a good fit for their usecase which may be better fit
> by a small custom application.
>
> Also people have a hard time understanding even the "basic" concepts,
> for various reasons.
>
> I have seen someone trying to build a simple processing chain for
> streaming audio
> and setting up a proprietary application as a JACK client.
> That was interesting to watch. It took quite some time for him to learn
> how to even build, install and use JACK
> in a meaningful way, even with me providing some help. In the end it
> worked out for testing
> and evaluation purposes but I'd never seriously consider that ready for
> production usage.
>
> This may sound harsh, but this stuff is simply not a nice choice for
> mainstream production use
> and so are many things in the LAU universe.
> ___
> 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

[Markus Seeber]

On 09/23/2016 05:13 PM, Paul Davis wrote:
> The last time I was working with such a person was deeply illustrative: a
> small technology company doing audio on raspberry pi and beagle boards.
> Using JACK. Having an insanely hard time even getting it work. Even with me
> sitting in with them. Their experience is common. Maybe even the norm. We
> never targetted JACK for such uses (focusing on desktop scenarios).
> Developers think it is cool, was developed on the same OS as they are
> running their new embedded platforms - awesome! Except ... not so much.
>
Exactly what I have experienced. It is all well for prototypes and for
testing out stuff,
but when things become serious, it all falls apart and people may notice,
that jack is not even a good fit for their usecase which may be better fit
by a small custom application.

Also people have a hard time understanding even the "basic" concepts,
for various reasons.

I have seen someone trying to build a simple processing chain for
streaming audio
and setting up a proprietary application as a JACK client.
That was interesting to watch. It took quite some time for him to learn
how to even build, install and use JACK
in a meaningful way, even with me providing some help. In the end it
worked out for testing
and evaluation purposes but I'd never seriously consider that ready for
production usage.

This may sound harsh, but this stuff is simply not a nice choice for
mainstream production use
and so are many things in the LAU universe.
___
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 Fri, Sep 23, 2016 at 10:12 AM, Patrick Shirkey <
pshir...@boosthardware.com> wrote:

>
> > Because we've done a fucking piss-poor job of licensing, packaging and
> > promoting technology in ways that make sense to the overwhelming majority
> > of developers and users.
> >
>
> If this is correct the trick appears to be having strong brand awareness
> and releasing the API on github?
>

strong brand awareness is hard and often costly. especially in a world as
absurdly competitive as the DAW-related market.

how many competitors does Photoshop have? how many viable, amazing DAWs are
there?


>
> I don't know how many but if they have gone to the trouble of creating the
> port then all they have to do is package and release it.


Wrong.


> They don't even
> really need to invest in marketing it because we do that for them.
>

You have to be kidding me.


>
> The issue is not how to deploy but when to deploy.


Sorry, no.
___
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 Fri, Sep 23, 2016 at 12:50 AM, Patrick Shirkey <
> pshir...@boosthardware.com> wrote:
>
>>
>> > On 09/22/2016 07:30 PM, Tito Latini wrote:
>> >> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote:
>> >> [...]
>> >>> > Ableton have now done that, albeit by circumventing the hardest
>> parts
>> >>> of
>> >>> > the problem (a tempo map with varying meter and tempo).
>> >> What?
>> >>
>> >> I repeat: that's not an innovation.
>> >
>> > Did anyone say it was? Why does it matter if it's innovation?
>> >
>> > Compared to all the prior-art, I suppose the interesting part of Link
>> is
>> > momentum behind it, along with the apple-style dictated protocol: take
>> > it as-is or leave it. Not the usual years of consortium design
>> > discussions which may or may not eventually result in consensus and
>> more
>> > like a floss-like benevolent dictator style (think jack, or LV2).
>> >
>> > The closest thing to innovation is "Pro Audio company that usually
>> does
>> > closed-source proprietary software publishes an API and reference
>> > implementation under GPLv2" and it work on GNU/Linux, too.
>> >
>> > That's pretty cool IMHO and I wish more companies would do that!
>> >
>> > Also coming up with a protocol is the easier part. Documenting it,
>> > pushing it out to users, gaining traction in the industry etc is the
>> > hard part.
>> >
>>
>> Only for Professional Audio. There are plenty of examples of Open Source
>> projects leading the field in other markets.
>>
>
> There are no fields I know of where open source leads in terms of end-user
> visible software applications.
>
> And in terms of non-end-user visible software applications, Linux has
> permeated just as deeply into pro audio as anywhere else (perhaps even
> more
> so).
>
>
>
>>
>> There are now numerous examples of real companies with real incomes
>> contributing directly to open source API's/frameworks/projects without
>> having to retain explicit ownership/control and branding rights.
>>
>
> No matter what Ableton or anyone may or may not write, you cannot release
> something under GPLv2 and retain "explicit ownership/control", and
> branding
> rights are of limited value in this domain.
>
>
>
>>
>> Why is it that after so many years, effort and examples such as the
>> Linux
>> Audio Consortium, the Linux Audio Conference, ALSA, JACK, LV2, Ardour we
>> still encounter this attitude from the proprietary players?
>>
>
> Because we've done a fucking piss-poor job of licensing, packaging and
> promoting technology in ways that make sense to the overwhelming majority
> of developers and users.
>

If this is correct the trick appears to be having strong brand awareness
and releasing the API on github?


> Do you have any idea how many companies I've interacted who are 100% aware
> of JACK (and maybe even a little in awe of some of what it can do) and may
> even have developed versions of their software that use it, but that
> cannot
> figure out how they could ever deploy them?
>

I don't know how many but if they have gone to the trouble of creating the
port then all they have to do is package and release it. They don't even
really need to invest in marketing it because we do that for them.

The issue is not how to deploy but when to deploy. The generous POV is
that everyone except Harrison is still waiting for the market to "mature".
The cynical POV is that something is actively stopping them from taking
the plunge.

According to some reports it's a good way to make some extra cash money
without having to actually release anything publicly. Just mentioning that
you have a Linux port is enough to get the funds flowing for "alternate"
development priorities.



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

[Paul Davis]

On Fri, Sep 23, 2016 at 10:03 AM, Patrick Shirkey <
pshir...@boosthardware.com> wrote:

>
>
> One can draw reasonable conclusions based on the evidence at hand.
>

You don't have any evidence other than the absence of evidence.
 >

> >
> > How many times is it necessary for someone to explain that JACK and AL
> are
> > NOT competing APIs ?
> >
>
> Sorry, if I can't just trust you on that statement. Only time will tell
> but from my perspective they are currently in an aggressive position
> against JACK.
>

Rui explained in a reasonably level of technical detail why this is so.
Your belief about this is just wrong.

You also conflate JACK transport (the only part of JACK that has even the
slightest connection with AL) with JACK itself. From the point of
developers, these are two wholly different things. There are lots and lots
of JACK-aware applications that do not use JACK transport.


> They haven't made any public announcements to the contrary, corrections or
> retractions and they certainly haven't released a Linux port of AL so as
> far as I (and I presume many others) are concerned the statement still
> stands. The proof is in the pudding really.
>

Aaww  poor thing. A company doesn't release a version of its
flagship product on your preferred platform and so they are evil.


> If Harrison, Autodesk and others CAN do it then why "CAN'T" Ableton
> especially now that they are "apparently" embracing Open Source, devoting
> resources and even have some "good will" from some highly regarded Linux
> Audio Developers.
>

and won't that be valuable. Yeah, LAD developers ... we've got the goods
everyone else wants. Please Patrick, give it a break. We're a tiny niche
inside a tiny niche. If you actually spent time with the people who work
for NI, Ableton, Waves, Steinberg, and many more, you'd know that they are
well aware of the audio technology on Linux BUT THEY CHOOSE NOT TO USE IT
(much). Can you wrap your head around this basic concept? They came, they
saw, they moved on?

The last time I was working with such a person was deeply illustrative: a
small technology company doing audio on raspberry pi and beagle boards.
Using JACK. Having an insanely hard time even getting it work. Even with me
sitting in with them. Their experience is common. Maybe even the norm. We
never targetted JACK for such uses (focusing on desktop scenarios).
Developers think it is cool, was developed on the same OS as they are
running their new embedded platforms - awesome! Except ... not so much.
___
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 Fri, Sep 23, 2016 at 6:00 AM, Patrick Shirkey
> > wrote:
>
>>
>> I suppose that their marketing department has decided that Linux
>> Developers/Users don't represent a big enough share of the market to
>> justify committing more resources to the platform.
>>
>
> You have no idea what their marketing department has decided. Admit it.
>

One can draw reasonable conclusions based on the evidence at hand.

>
>>
>> However JACK also runs on the other two main platforms so what is their
>> rational behind completely ignoring it altogether while committing
>> resources to creating a competing API?
>>
>
> How many times is it necessary for someone to explain that JACK and AL are
> NOT competing APIs ?
>

Sorry, if I can't just trust you on that statement. Only time will tell
but from my perspective they are currently in an aggressive position
against JACK.


>
>>
>> Keep in mind that they have explicitly stated that Ableton Live will
>> NEVER
>> run on Linux. It seems a bit hypocritical to me that highly regarded
>> people from this community are proposing to add support for the new
>> protocol and at the same time questioning why there is (still)
>> antagonism
>> towards Ableton.
>>
>
> I have no idea what statement you are referring to, but if I was to guess
> it might be when Gerhard Behles, one of the company's (and software's)
> founders was at LAC in Berlin in 2007. Which means basically before
> Android
> took over the world and Chromebooks and ...
>

To paraphrase Peter Pan, "NEVER is an awfully long time..."

They haven't made any public announcements to the contrary, corrections or
retractions and they certainly haven't released a Linux port of AL so as
far as I (and I presume many others) are concerned the statement still
stands. The proof is in the pudding really.

Quite simply:

Do they have an official Linux port? Do they officially support JACK?

Now that it is cool to release Open Source products they appear to have
jumped on the band wagon but until they actually bite the bullet and
release their Linux port of AL and integrate with JACK on all platforms
then it shouldn't offend anyone if I am (or anyone else from round here
is) suspicious of their intentions.


> If so, this is a statement that is getting on for a decade of aging, and
> it
> is absurd to view this as policy. You have absolutely no idea what Ableton
> is and is not doing with Linux, or what its policies (if there are indeed
> any) toward Linux are. I suggest you regard that statement as a bit of
> off-its-time sensible marketing wisdom from nearly a decade ago, and move
> on.
>
>
>>
>> Other proprietary companies have no problems releasing their software to
>> run on Linux.
>
>
> And many others are NOT.  So what would that mean? (that's a rhetorical
> question)
>

If Harrison, Autodesk and others CAN do it then why "CAN'T" Ableton
especially now that they are "apparently" embracing Open Source, devoting
resources and even have some "good will" from some highly regarded Linux
Audio Developers.

Seems like a marketing blunder on their part in regards to winning hearts
and minds in the overall Linux sector but other people view the situation
with more sinister implications.

On the flipside if adopting Link into the Linux Audio Stack means Ableton
feels more committed to LINUX and makes some tangible movements in this
direction then we might have a publicity coup on our hands. However I'm
not betting on that outcome due to their record so far.

IMO, the time/effort required to support Link across the board could be
better spent on fixing the looping issue in JACK.

If/When there is some momentum for Link adoption I will update the Linux
Audio Stack diagram to maintain transparency but I am not sold on the real
value of Link to Linux Audio at this point. Seems like a one sided affair
where they get brand promotion without having to actually commit to Linux
Audio.

Or to quote from Captain Hook this time "Bad form Peter".


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

[Paul Davis]

On Fri, Sep 23, 2016 at 9:01 AM, Paul Davis 
wrote:

>
>
> There are no fields I know of where open source leads in terms of end-user
> visible software applications.
>

oops. except for web browsers.


>
___
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 Fri, Sep 23, 2016 at 6:00 AM, Patrick Shirkey  wrote:

>
> I suppose that their marketing department has decided that Linux
> Developers/Users don't represent a big enough share of the market to
> justify committing more resources to the platform.
>

You have no idea what their marketing department has decided. Admit it.


>
> However JACK also runs on the other two main platforms so what is their
> rational behind completely ignoring it altogether while committing
> resources to creating a competing API?
>

How many times is it necessary for someone to explain that JACK and AL are
NOT competing APIs ?


>
> Keep in mind that they have explicitly stated that Ableton Live will NEVER
> run on Linux. It seems a bit hypocritical to me that highly regarded
> people from this community are proposing to add support for the new
> protocol and at the same time questioning why there is (still) antagonism
> towards Ableton.
>

I have no idea what statement you are referring to, but if I was to guess
it might be when Gerhard Behles, one of the company's (and software's)
founders was at LAC in Berlin in 2007. Which means basically before Android
took over the world and Chromebooks and ...

If so, this is a statement that is getting on for a decade of aging, and it
is absurd to view this as policy. You have absolutely no idea what Ableton
is and is not doing with Linux, or what its policies (if there are indeed
any) toward Linux are. I suggest you regard that statement as a bit of
off-its-time sensible marketing wisdom from nearly a decade ago, and move
on.


>
> Other proprietary companies have no problems releasing their software to
> run on Linux.


And many others are NOT.  So what would that mean? (that's a rhetorical
question)
___
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 Fri, Sep 23, 2016 at 12:50 AM, Patrick Shirkey <
pshir...@boosthardware.com> wrote:

>
> > On 09/22/2016 07:30 PM, Tito Latini wrote:
> >> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote:
> >> [...]
> >>> > Ableton have now done that, albeit by circumventing the hardest parts
> >>> of
> >>> > the problem (a tempo map with varying meter and tempo).
> >> What?
> >>
> >> I repeat: that's not an innovation.
> >
> > Did anyone say it was? Why does it matter if it's innovation?
> >
> > Compared to all the prior-art, I suppose the interesting part of Link is
> > momentum behind it, along with the apple-style dictated protocol: take
> > it as-is or leave it. Not the usual years of consortium design
> > discussions which may or may not eventually result in consensus and more
> > like a floss-like benevolent dictator style (think jack, or LV2).
> >
> > The closest thing to innovation is "Pro Audio company that usually does
> > closed-source proprietary software publishes an API and reference
> > implementation under GPLv2" and it work on GNU/Linux, too.
> >
> > That's pretty cool IMHO and I wish more companies would do that!
> >
> > Also coming up with a protocol is the easier part. Documenting it,
> > pushing it out to users, gaining traction in the industry etc is the
> > hard part.
> >
>
> Only for Professional Audio. There are plenty of examples of Open Source
> projects leading the field in other markets.
>

There are no fields I know of where open source leads in terms of end-user
visible software applications.

And in terms of non-end-user visible software applications, Linux has
permeated just as deeply into pro audio as anywhere else (perhaps even more
so).



>
> There are now numerous examples of real companies with real incomes
> contributing directly to open source API's/frameworks/projects without
> having to retain explicit ownership/control and branding rights.
>

No matter what Ableton or anyone may or may not write, you cannot release
something under GPLv2 and retain "explicit ownership/control", and branding
rights are of limited value in this domain.



>
> Why is it that after so many years, effort and examples such as the Linux
> Audio Consortium, the Linux Audio Conference, ALSA, JACK, LV2, Ardour we
> still encounter this attitude from the proprietary players?
>

Because we've done a fucking piss-poor job of licensing, packaging and
promoting technology in ways that make sense to the overwhelming majority
of developers and users.

Do you have any idea how many companies I've interacted who are 100% aware
of JACK (and maybe even a little in awe of some of what it can do) and may
even have developed versions of their software that use it, but that cannot
figure out how they could ever deploy them?
___
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 Fri, Sep 23, 2016 at 4:42 AM, Tito Latini  wrote:

> On Thu, Sep 22, 2016 at 04:36:17PM -0500, Paul Davis wrote:
> > On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini 
> wrote:
> >
> > > On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis wrote:
> > > > The innovation is defining an API and protocol based on 3 concepts:
> > > >
> > > > tempo synchronization
> > >
> > > an integral to get the position with the new bpm
> > >
> >
> > across a network? with multiple tempo masters?
>
> I respectfully think you don't understand the technical problem.
>

   [ description ]

and yet ... no such protocol exists.

so it must all be very easy, particularly the part about gaining widespread
adoption, and yet nobody has done it, despite 30 years of protocols like
MIDI Clock, MIDI timecode, LTC and more.

puzzling, eh?
___
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]

"IMO anyone who doesn't know about JACK and claims to be a professional
audio developer has dubious credentials."

I think this is an unfounded statement. Many professional audio developers
work on Windows with ASIO
and are both professional and some of them definitely unaware of JACK.

"Keep in mind that they have explicitly stated that Ableton Live will NEVER
run on Linux."

Can you please link to this statement?



On Fri, Sep 23, 2016 at 1:00 PM, Patrick Shirkey  wrote:

>
> > On Thu, 2016-09-22 at 19:58 +0200, Robin Gareus wrote:
> >> That's pretty cool IMHO and I wish more companies would do that!
> >>
> >> Also coming up with a protocol is the easier part. Documenting it,
> >> pushing it out to users, gaining traction in the industry etc is the
> >> hard part.
> >
> > I agree with this. This thread has been a little bit agressive and I
> > don't really understand why.
> >
> > From my point of view, integration with AL will probably have
> > interesting side effects among all musical applications. Imagine
> > jam/performance sessions with musicians combining many different DAWs
> > and loopers running on multiple platforms.
> >
> > The whole point of such a protocol as they've developed it is to
> > increase creativity and to open up possibilities for collaboration and
> > new musical ideas. Isn't that one of the reasons we like to hangout on
> > mailing lists like this one?
> >
>
> Some us us disagree that this IS the "whole point" of Link.
>
> IMO anyone who doesn't know about JACK and claims to be a professional
> audio developer has dubious credentials. In addition there are other
> existing API's as Tito has explained that predate Link.
>
> Given the fractured history that Ableton has with Open Source development
> and Linux support it should not come as a surprise to anyone on this list
> that there is some disagreement over the validity of their release process
> / marketing campaign.
>
> I suppose that their marketing department has decided that Linux
> Developers/Users don't represent a big enough share of the market to
> justify committing more resources to the platform.
>
> However JACK also runs on the other two main platforms so what is their
> rational behind completely ignoring it altogether while committing
> resources to creating a competing API?
>
> Keep in mind that they have explicitly stated that Ableton Live will NEVER
> run on Linux. It seems a bit hypocritical to me that highly regarded
> people from this community are proposing to add support for the new
> protocol and at the same time questioning why there is (still) antagonism
> towards Ableton.
>
> Other proprietary companies have no problems releasing their software to
> run on Linux. For example Flame (Autodesk) runs perfectly fine on Linux as
> does Vmware, Oracle, etc...  Even the Tesla cars are running Linux for
> their multimedia systems.  Steam has their own Linux Distribution. It's
> not like it there is no precedence for Ableton to release a binary only
> Linux port.  More so if they genuinely want Linux Audio Developers to
> support their profit margins and integrate our software/platform with
> their product(s) at our expense/time/resources.
>
> Of course everyone is free to do what they want but don't try to pretend
> that it's a shock that some of us are not enthused about this new product.
> That comes across as lack of insight or outright BS.
>
>
>
> --
> Patrick Shirkey
> Boost Hardware Ltd
>
> ___
> 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

[Ralf Mardorf]

On Fri, 23 Sep 2016 13:00:08 +0200, Patrick Shirkey wrote:
>> On Thu, 2016-09-22 at 19:58 +0200, Robin Gareus wrote:
>>> That's pretty cool IMHO and I wish more companies would do that!
>>>
>>> Also coming up with a protocol is the easier part. Documenting it,
>>> pushing it out to users, gaining traction in the industry etc is the
>>> hard part.
>>
>> The whole point of such a protocol as they've developed it is to
>> increase creativity and to open up possibilities for collaboration
>> and new musical ideas. Isn't that one of the reasons we like to
>> hangout on mailing lists like this one?
>
>Some us us disagree that this IS the "whole point" of Link.  

>From my user point of view I welcome Linux apps integrating Ableton
Link. Actually I don't know if I really need it, but it doesn't harm to
have the opportunity to use it. Some subscribers explained that it's
not just another way to sync by one master and several slaves.

I've got a question. If I e.g. have one device at 180 BPM and another
at 90 BPM, they both could keep the their own tempo and would play in
sync? This double/half speed thing is a common MIDI sync issue.

Regards,
Ralf
___
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 Thu, 2016-09-22 at 19:58 +0200, Robin Gareus wrote:
>> That's pretty cool IMHO and I wish more companies would do that!
>>
>> Also coming up with a protocol is the easier part. Documenting it,
>> pushing it out to users, gaining traction in the industry etc is the
>> hard part.
>
> I agree with this. This thread has been a little bit agressive and I
> don't really understand why.
>
> From my point of view, integration with AL will probably have
> interesting side effects among all musical applications. Imagine
> jam/performance sessions with musicians combining many different DAWs
> and loopers running on multiple platforms.
>
> The whole point of such a protocol as they've developed it is to
> increase creativity and to open up possibilities for collaboration and
> new musical ideas. Isn't that one of the reasons we like to hangout on
> mailing lists like this one?
>

Some us us disagree that this IS the "whole point" of Link.

IMO anyone who doesn't know about JACK and claims to be a professional
audio developer has dubious credentials. In addition there are other
existing API's as Tito has explained that predate Link.

Given the fractured history that Ableton has with Open Source development
and Linux support it should not come as a surprise to anyone on this list
that there is some disagreement over the validity of their release process
/ marketing campaign.

I suppose that their marketing department has decided that Linux
Developers/Users don't represent a big enough share of the market to
justify committing more resources to the platform.

However JACK also runs on the other two main platforms so what is their
rational behind completely ignoring it altogether while committing
resources to creating a competing API?

Keep in mind that they have explicitly stated that Ableton Live will NEVER
run on Linux. It seems a bit hypocritical to me that highly regarded
people from this community are proposing to add support for the new
protocol and at the same time questioning why there is (still) antagonism
towards Ableton.

Other proprietary companies have no problems releasing their software to
run on Linux. For example Flame (Autodesk) runs perfectly fine on Linux as
does Vmware, Oracle, etc...  Even the Tesla cars are running Linux for
their multimedia systems.  Steam has their own Linux Distribution. It's
not like it there is no precedence for Ableton to release a binary only
Linux port.  More so if they genuinely want Linux Audio Developers to
support their profit margins and integrate our software/platform with
their product(s) at our expense/time/resources.

Of course everyone is free to do what they want but don't try to pretend
that it's a shock that some of us are not enthused about this new product.
That comes across as lack of insight or outright BS.



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

[Daniel Swärd]

On Thu, 2016-09-22 at 19:58 +0200, Robin Gareus wrote:
> That's pretty cool IMHO and I wish more companies would do that!
> 
> Also coming up with a protocol is the easier part. Documenting it,
> pushing it out to users, gaining traction in the industry etc is the
> hard part.

I agree with this. This thread has been a little bit agressive and I
don't really understand why.

>From my point of view, integration with AL will probably have
interesting side effects among all musical applications. Imagine
jam/performance sessions with musicians combining many different DAWs
and loopers running on multiple platforms.

The whole point of such a protocol as they've developed it is to
increase creativity and to open up possibilities for collaboration and
new musical ideas. Isn't that one of the reasons we like to hangout on
mailing lists like this one?

/Daniel
___
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 Thu, Sep 22, 2016 at 04:36:17PM -0500, Paul Davis wrote:
> On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini  wrote:
> 
> > On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis wrote:
> > > The innovation is defining an API and protocol based on 3 concepts:
> > >
> > > tempo synchronization
> >
> > an integral to get the position with the new bpm
> >
> 
> across a network? with multiple tempo masters?

I respectfully think you don't understand the technical problem.

We send/receive informations about the time, the change of the tempo
and/or the position of a beat, the updated number of the participants,
the time window to get the next temporal change, a message "too soon"
to discard or defer a change, the minimal time window, latency, etc,
but not the performance of the change.

That's a protocol.

The integral is software-side, not across the network. It's not always
necessary because it depends on the musical instrument. For example, a
string quartet uses a particular curve to change the tempo; the curve
is possibly different with pizzicato; a drum machine plays in ritardo
or fills the time window with a roll. The modus operandi is arbitrary
for an application, the network is used to share the information about
the clock and the possible changes (start-time, end-time, from-bpm,
to-bpm, from-position, to-beat, etc).

Under the hood, the synchronization of the beat is the change of a
local bpm. For example, tempo-change + beat alignment is a combination
of two integrals (software-side) if the instrument plays accelerando
or ritardando. The coder of the program/library is responsible of the
curve-palette and the optimization.

One common protocol to communicate, many programs/libraries to play.
___
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/22/2016 07:30 PM, Tito Latini wrote:
>> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote:
>> [...]
>>> > Ableton have now done that, albeit by circumventing the hardest parts
>>> of
>>> > the problem (a tempo map with varying meter and tempo).
>> What?
>>
>> I repeat: that's not an innovation.
>
> Did anyone say it was? Why does it matter if it's innovation?
>
> Compared to all the prior-art, I suppose the interesting part of Link is
> momentum behind it, along with the apple-style dictated protocol: take
> it as-is or leave it. Not the usual years of consortium design
> discussions which may or may not eventually result in consensus and more
> like a floss-like benevolent dictator style (think jack, or LV2).
>
> The closest thing to innovation is "Pro Audio company that usually does
> closed-source proprietary software publishes an API and reference
> implementation under GPLv2" and it work on GNU/Linux, too.
>
> That's pretty cool IMHO and I wish more companies would do that!
>
> Also coming up with a protocol is the easier part. Documenting it,
> pushing it out to users, gaining traction in the industry etc is the
> hard part.
>

Only for Professional Audio. There are plenty of examples of Open Source
projects leading the field in other markets.

IMO that is the main contributor to the perceived animosity to companies
like Ableton from *some* open source developers.

There are now numerous examples of real companies with real incomes
contributing directly to open source API's/frameworks/projects without
having to retain explicit ownership/control and branding rights.

The big exception seems to be professional audio where almost all the
major players (Harrison is a notable exception) want to invent the wheel
and go it alone.

Why is it that after so many years, effort and examples such as the Linux
Audio Consortium, the Linux Audio Conference, ALSA, JACK, LV2, Ardour we
still encounter this attitude from the proprietary players?




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

[Paul Davis]

On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini  wrote:

> On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis wrote:
> > The innovation is defining an API and protocol based on 3 concepts:
> >
> > tempo synchronization
>
> an integral to get the position with the new bpm
>

across a network? with multiple tempo masters?


>
> > beat alignment
>
> ask to live coders
>
> > phase alignment
>
> related to beat alignment
>

sometimes there's magic that comes from bringing things together even if
they are well known before hand.

i am aware of no attempt to define any kind of of protocol, API or SDK that
does what Link does. the fact that a few people on the edges of computer
music production have done some of them individually before doesn't really
change that.


>
> > Whatever you've done in incudine, it doesn't define an actual tempo map
> > that can and will be shared among applications, which was always the
> > sticking point for JACK to be able to do this. It isn't hard to define
> such
>
> You always think in JACK. I'm talking about an independent, public and
> possibly standard protocol; if you know the recipe, you write what you
> want. The implementation in JACK, a library from Ableton, etc, is a
> welcome side effect.
>

I'm not talking about just JACK. I'm talking about how hard it is to define
a standard for a shared tempo map that people will ACTUALLY use. There is
no such thing at this point in time. If there is one, it will come from
someone/some organization who can put immediate momentum behind it, because
the adoption cost of fitting someone else's model of a tempo map into each
application is high.


>
> I want the freedom to sync a little device in assembly. One time,
> without the necessity to check the updates of the "protocol" on the AL
> web page.
>

nobody is making you do anything. you can do whatever you want. but if you
want your "little device" to sync with other people's "little devices" then
there needs to be some joint understanding of how that is going to work. AL
is an example of someone trying to do that.


>
> You (not only Paul) are being much too defensive; perhaps I'm writing
> on the wrong list.
>

you seem to have reacted quite negatively and critically of AL, apparently
because, despite its GPLv2 license, it comes from a company that
traditionally uses a proprietary development and licensing model. i don't
understand this point of view.
___
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 Thu, Sep 22, 2016 at 07:58:03PM +0200, Robin Gareus wrote:
> [...]
> Also coming up with a protocol is the easier part. Documenting it,
> pushing it out to users, gaining traction in the industry etc is the
> hard part.

opus-codec is an example of authentic Art (rfc, code, etc) and not
genuflextion.
___
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 Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis wrote:
> The innovation is defining an API and protocol based on 3 concepts:
>
> tempo synchronization

an integral to get the position with the new bpm

> beat alignment

ask to live coders

> phase alignment

related to beat alignment

> Whatever you've done in incudine, it doesn't define an actual tempo map
> that can and will be shared among applications, which was always the
> sticking point for JACK to be able to do this. It isn't hard to define such

You always think in JACK. I'm talking about an independent, public and
possibly standard protocol; if you know the recipe, you write what you
want. The implementation in JACK, a library from Ableton, etc, is a
welcome side effect.

I want the freedom to sync a little device in assembly. One time,
without the necessity to check the updates of the "protocol" on the AL
web page.

You (not only Paul) are being much too defensive; perhaps I'm writing
on the wrong list.
___
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/22/2016 07:30 PM, Tito Latini wrote:
> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote:
> [...]
>> > Ableton have now done that, albeit by circumventing the hardest parts of
>> > the problem (a tempo map with varying meter and tempo).
> What?
> 
> I repeat: that's not an innovation.

Did anyone say it was? Why does it matter if it's innovation?

Compared to all the prior-art, I suppose the interesting part of Link is
momentum behind it, along with the apple-style dictated protocol: take
it as-is or leave it. Not the usual years of consortium design
discussions which may or may not eventually result in consensus and more
like a floss-like benevolent dictator style (think jack, or LV2).

The closest thing to innovation is "Pro Audio company that usually does
closed-source proprietary software publishes an API and reference
implementation under GPLv2" and it work on GNU/Linux, too.

That's pretty cool IMHO and I wish more companies would do that!

Also coming up with a protocol is the easier part. Documenting it,
pushing it out to users, gaining traction in the industry etc is the
hard part.

2c,
robin
___
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 Thu, Sep 22, 2016 at 12:30 PM, Tito Latini  wrote:

> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote:
> [...]
> > Ableton have now done that, albeit by circumventing the hardest parts of
> > the problem (a tempo map with varying meter and tempo).
>
> What?
>
> I repeat: that's not an innovation.
>

The innovation is defining an API and protocol based on 3 concepts:

tempo synchronization
beat alignment
phase alignment

Whatever you've done in incudine, it doesn't define an actual tempo map
that can and will be shared among applications, which was always the
sticking point for JACK to be able to do this. It isn't hard to define such
a map within the context of a single application - many apps have this.
Defining one that can be shared without people bitching about what's wrong
or what's missing is much harder.

Link sidesteps this by completely omitting it, along with the possibilities
it would make feasible.
___
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 Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote:
[...]
> Ableton have now done that, albeit by circumventing the hardest parts of
> the problem (a tempo map with varying meter and tempo).

What?

I repeat: that's not an innovation.

>From Incudine web page [1]:

Features

  [...]
  * Tempo change with arbitrary curves
  [...]


Public and visible to *all* from

commit 2fbf62068e50ef65e15a235454540ac4a22500ab
Author: Tito Latini 
Date:   Fri Oct 25 11:21:55 2013 +0200

complete temporal envelope

- new structure TEMPO-ENVELOPE

- new utilities: SET-TEMPO-ENVELOPE, TIME-AT, BPS-AT and BPM-AT

- the syntax for the #[... b.* ...] read-macro becomes:

#[NUM-OF-BEATS b.*]   ; *TEMPO* by default

#[NUM-OF-BEATS b.* TEMPO]

#[NUM-OF-BEATS b.* TEMPO-ENVELOPE OFFSET-IN-BEATS]


The source is in incudine/src/time.lisp [2]  (GPL v2)

If you read lisp, here is a part of the tutorial about tempo mapping
(the original is online [3] or with the source code
incudine/doc/html/tutorial_02.html or the text file
incudine/doc/tutorials/getting_start_2.cudo):

--[START TUTORIAL CUT]--

The structure TEMPO-ENVELOPE is specific for a temporal envelope.
The constructor is MAKE-TEMPO-ENVELOPE, and SET-TEMPO-ENVELOPE is
useful to change an existent instance.

;;; The utilities to get the time, the bps and the bpm are:

(time-at tempo-env beats  offset)

(bps-at tempo-env beats)

(bpm-at tempo-env beats)

;;; The syntax for the #[... b.* ...] read-macro is:

#[NUM-OF-BEATS b.*]   ; *TEMPO* by default

#[NUM-OF-BEATS b.* TEMPO]

#[NUM-OF-BEATS b.* TEMPO-ENVELOPE OFFSET-IN-BEATS]

;;; Example:

;;; After 8 beats, there is an acceleration from 60 to 120 bpm in 4 beats,
;;; with coeff 4 for the curvature. Then, after 2 beats, there is a
;;; deceleration from 120 to 96 bpm in 2 beats, with sinusoidal curvature.
SCRATCH> (defvar *tenv1* (make-tempo-envelope '(60 60 120 120 96) '(8 4 2 2)
  :curve '(:step 4 :step :sin)))
*TENV1*
SCRATCH> (loop for beats below 20 by 0.5 collect (time-at *tenv1* beats))
(0.0d0 0.5d0 1.0d0 1.5d0 2.0d0 2.5d0 3.0d0 3.5d0 4.0d0 4.5d0 5.0d0 5.5d0 6.0d0
 6.5d0 7.0d0 7.5d0 8.0d0 8.498612626829395d0 8.993299378541845d0
 9.481513456442876d0 9.959055899352716d0 10.419003790659431d0
 10.849943170489647d0 11.233055600417206d0 11.537314720727547d0
 11.787314720727547d0 12.037314720727547d0 12.287314720727547d0
 12.537314720727547d0 12.790429835847638d0 13.060025984954574d0
 13.352929835847638d0 13.662314720727547d0 13.974814720727547d0
 14.287314720727547d0 14.599814720727547d0 14.912314720727547d0
 15.224814720727547d0 15.537314720727547d0 15.849814720727547d0)
SCRATCH> (loop for beats below 20 by 0.5 collect (bps-at *tenv1* beats))
(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0
 1.0d0 1.0d0 1.0d0 1.0d0 0.9939482867384511d0 0.9839706983599575d0
 0.9675204361700447d0 0.9403985389889412d0 0.8956820902047142d0
 0.8219571299439862d0 0.7004052197806022d0 0.5d0 0.5d0 0.5d0 0.5d0 0.5d0
 0.5183058261758408d0 0.5625d0 0.6066941738241592d0 0.625d0 0.625d0 0.625d0
 0.625d0 0.625d0 0.625d0 0.625d0 0.625d0)
SCRATCH> (loop for beats below 20 by 0.5 collect (bpm-at *tenv1* beats))
(60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0
 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.0d0 60.36531356866102d0
 60.97742554733141d0 62.01419397145924d0 63.80273629998226d0
 66.98805374827423d0 72.99650774254955d0 85.6646956725917d0 120.0d0 120.0d0
 120.0d0 120.0d0 120.0d0 115.76177030980232d0 106.67d0
 98.8966147833654d0 96.0d0 96.0d0 96.0d0 96.0d0 96.0d0 96.0d0 96.0d0 96.0d0)
SCRATCH> *sample-rate*
48000.0d0
SCRATCH> (loop for beats below 20 by 0.5 collect #[1 beat *tenv1* beats])
(48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0
 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0 48000.0d0
 48000.0d0 47933.40608781097d0 47678.37017000858d0 47179.23982144708d0
 46356.31299892179d0 44999.536042394655d0 42762.58901457268d0
 39074.486868373184d0 32993.834411419215d0 26604.43777489638d0 24000.0d0
 24000.0d0 24000.0d0 24149.525525764348d0 25090.140682897298d0 27000.0d0
 28909.859317102702d0 29850.474474235652d0 3.0d0 3.0d0 3.0d0
 3.0d0 3.0d0 3.0d0 3.0d0 3.0d0)

--[STOP TUTORIAL CUT]--


[1] http://incudine.sourceforge.net/

[2] https://raw.githubusercontent.com/titola/incudine/master/src/time.lisp

[3] http://incudine.sourceforge.net/tutorial_02.html
___
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 Thu, Sep 22, 2016 at 2:34 AM, Patrick Shirkey  wrote:

>
> It seems that the lack of interest in adding similar functionality to JACK
> has opened up a gap in the "market".
>

there was no lack of interest, but rather an inability to come up with an
abstraction for defining loops and musical time that could be widely used.

Ableton have now done that, albeit by circumventing the hardest parts of
the problem (a tempo map with varying meter and tempo).
___
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/21/2016 11:24 AM, Perry Nguyen wrote:
>>
>> Though after reading your post to LAD a couple times over it seems like
>> there is possibly overlooked but important incongruity between BPM and
>> "linear/real-time".. and perhaps that limits the ability of word-clock
>> time designators like JACK from seamlessly following BPM? If that is the
>> case it is still unclear to me what the specific technical details of
>> that incongruity are.
>>
>
> (continuing my own babbling...:))
>
> read this?
>
> http://github.com/jackaudio/jackaudio.github.com/wiki/TransportLimitations
> (JACK Transport Limitations)
>
> ok. now from the top of my head.
>
> a. jack-transport/timebase (JT) is a centralized master/slave model,
> including its API approach; corollaries follows: all JT clients start
> and stop on demand and at the same time; netjack clients might drift
> apart, unless they implement some sort of PLL/DLL device (anyway, this
> assumes one of the participants is master); time reference is absolute
> frame position, constant sample-rate (frames/second), starting from a
> designated master application, linear (tape-like) timeline model (a
> song, session or project as a whole length continuous composition or
> arrangement).
>
> b. ableton-link (AL) is a distributed metronome facility and API; any AL
> client may or not be playing its thing on any given time, but when they
> play,  they *should* start and sync (internally on their own premises)
> on beat boundaries on their own best-fit strategy model; time reference
> is tempo (BPM; beats/minute); tempo changes are broadcasted (well, dang
> truth is multicasted), may be initiated by any participant, then each
> other participant may react accordingly (or not) on their own chance,
> next cycle or phase, whichever fits best their own designed playback
> model--this is why, AL is more suited for loop-based contraptions that
> straight linear-tape model ones.
>
> you can map AL to JT (timebase) if you will, but it's one master's job
> to do it--make the time calculations according to its own master, static
> tempo-map.
>
> hth.
> cheers
> --
> rncbc aka. Rui Nuno Capela

It seems that the lack of interest in adding similar functionality to JACK
has opened up a gap in the "market".

Is there any specific reason that JACK *cannot* be used to enable a
similar looping mechanism via the transport control or in parallel?




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

[Rui Nuno Capela]

On 09/21/2016 11:24 AM, Perry Nguyen wrote:
>
> Though after reading your post to LAD a couple times over it seems like
> there is possibly overlooked but important incongruity between BPM and
> "linear/real-time".. and perhaps that limits the ability of word-clock
> time designators like JACK from seamlessly following BPM? If that is the
> case it is still unclear to me what the specific technical details of
> that incongruity are.
>

(continuing my own babbling...:))

read this?
 
http://github.com/jackaudio/jackaudio.github.com/wiki/TransportLimitations 
(JACK Transport Limitations)

ok. now from the top of my head.

a. jack-transport/timebase (JT) is a centralized master/slave model, 
including its API approach; corollaries follows: all JT clients start 
and stop on demand and at the same time; netjack clients might drift 
apart, unless they implement some sort of PLL/DLL device (anyway, this 
assumes one of the participants is master); time reference is absolute 
frame position, constant sample-rate (frames/second), starting from a 
designated master application, linear (tape-like) timeline model (a 
song, session or project as a whole length continuous composition or 
arrangement).

b. ableton-link (AL) is a distributed metronome facility and API; any AL 
client may or not be playing its thing on any given time, but when they 
play,  they *should* start and sync (internally on their own premises) 
on beat boundaries on their own best-fit strategy model; time reference 
is tempo (BPM; beats/minute); tempo changes are broadcasted (well, dang 
truth is multicasted), may be initiated by any participant, then each 
other participant may react accordingly (or not) on their own chance, 
next cycle or phase, whichever fits best their own designed playback 
model--this is why, AL is more suited for loop-based contraptions that 
straight linear-tape model ones.

you can map AL to JT (timebase) if you will, but it's one master's job 
to do it--make the time calculations according to its own master, static 
tempo-map.

hth.
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

[Robin Gareus]

On 09/21/2016 12:24 PM, Perry Nguyen wrote:
> I am still vaguely under the impression that if a Timebase master client is
> Link-capable then any transport-aware client (e.g. most LAU apps today)
> would be able to follow any tempo changes described by the master and
> therefore automatically have "Link support"

Theoretically, yes. A jack timebase master is supposed to translate
current absolute position to musical time. It's mainly useful for
tempo-maps.

Ableton Link does not provide an absolute reference, so the client would
have to maintain an internal count depending on transport state, infer
that information and keep track.

Still jack-position is versatile enough to represent information
provided by Link:

http://jackaudio.org/files/docs/html/structjack__position__t.html

The real question is if it's useful and how many jack-apps
can cope with potentially non-linearity WRT to absolute jack transport
sample time.

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

[Perry Nguyen]

hi,

I've posted about Ableton Link a number of times now on LM and LAD but I
was never satisfactorily responded to..

Here's my post from LM https://linuxmusicians.com/viewtopic.php?f=1=14913
here's the same thing I posed on LAD
http://linux-audio.4202.n7.nabble.com/ableton-link-and-live-tempo-changing-td99835.html

well I hope someone sees my post this time. But anyway I'm just copying my
message from LM if anyone has opinions:

Hey rui,

I've noticed the discussions on github/LAD (the latter of which i am still
unable to post on[image: :?] ) and your PR to Link. It seems like you've
made reasonable progress with it-- can you comment on how feasible the
ideas I described in my original post are?

I am still vaguely under the impression that if a Timebase master client is
Link-capable then any transport-aware client (e.g. most LAU apps today)
would be able to follow any tempo changes described by the master and
therefore automatically have "Link support"-- from my understanding the
JACK Timebase includes transport control and BPM information (though maybe
not beat sync information like Link?). Then can't a timebase master client
be Link-obedient just in regards to BPM but operate transport independently
(since Link doesn't have transport a transport representation anyway)?

Though after reading your post to LAD a couple times over it seems like
there is possibly overlooked but important incongruity between BPM and
"linear/real-time".. and perhaps that limits the ability of word-clock time
designators like JACK from seamlessly following BPM? If that is the case it
is still unclear to me what the specific technical details of that
incongruity are.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

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] 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] 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] 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

Re: [LAD] 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 
>>> 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

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

Re: [LAD] aBLETON lINK

[Patrick Shirkey]

> 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.

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.2 btc

-- 
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 GPL...

[Rui Nuno Capela]

> On 09/15/2016 03:33 PM, Rui Nuno Capela wrote:
>> On 09/15/2016 11:58 AM, Daniel Swärd wrote:
>>>
>>> Now that Ableton Link has been publically released as GPL, does anyone
>>> have any ideas/plans to integrate it into your projects?
>>>
>>> http://ableton.github.io/link/
>>
>> i do (qtractor)
>>
>
> hmm..
>
> been trying converting the linkhut example to jack and ...
>
> it plays well, links well with peers over the W/LAN, but dang it does
> draw upwards any cpu load chart over here :/~
>

maybe i jumped too early

the simple addition of "-O2" to cflags made (a lot of) a difference ;)

nevertheless
-- 
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 GPL...

[Rui Nuno Capela]

On 09/15/2016 03:33 PM, Rui Nuno Capela wrote:
> On 09/15/2016 11:58 AM, Daniel Swärd wrote:
>> Hi.
>>
>> Now that Ableton Link has been publically released as GPL, does anyone
>> have any ideas/plans to integrate it into your projects?
>>
>> http://ableton.github.io/link/
>>
>
> i do (qtractor)
>

hmm..

been trying converting the linkhut example to jack and ...

it plays well, links well with peers over the W/LAN, but dang it does 
draw upwards any cpu load chart over here :/~

who's willing to try this?

here's my (early) test code:
(please note that it includes the needed ableton::Link stuff verbatim):
   http:/www.rncbc.org/datahub/ableton-link-jack-1.tar.gz

nb. you also need asio-dev(el) installed (http://think-async.com/)

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 GPL...

[Joël Krähemann]

Hi

GSequencer is pure C may be doing a C interface to communicate with such
applications or devices.

cheers,
Joël


On Thu, Sep 15, 2016 at 5:14 PM, Paul Davis 
wrote:

> It will definitely be on a list for Ardour somewhere. Right now my
> Ableton-related activities with Ardour relate to fairly deep support of
> their Push 2 surface rather than Link. It would certainly be nice to see
> Link support, but not sure what the priority will be. I have another
> entirely new branch that is developing Live-like "clip launch" facilities
> for Ardour, and it is likely that Link support would want to piggy back on
> some of the concepts being developed there (notably beat/bar
> synchronization).
>
> On Thu, Sep 15, 2016 at 5:58 AM, Daniel Swärd  wrote:
>
>> Hi.
>>
>> Now that Ableton Link has been publically released as GPL, does anyone
>> have any ideas/plans to integrate it into your projects?
>>
>> http://ableton.github.io/link/
>>
>> /Daniel
>> ___
>> 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
>
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Ableton Link GPL...

[Paul Davis]

It will definitely be on a list for Ardour somewhere. Right now my
Ableton-related activities with Ardour relate to fairly deep support of
their Push 2 surface rather than Link. It would certainly be nice to see
Link support, but not sure what the priority will be. I have another
entirely new branch that is developing Live-like "clip launch" facilities
for Ardour, and it is likely that Link support would want to piggy back on
some of the concepts being developed there (notably beat/bar
synchronization).

On Thu, Sep 15, 2016 at 5:58 AM, Daniel Swärd  wrote:

> Hi.
>
> Now that Ableton Link has been publically released as GPL, does anyone
> have any ideas/plans to integrate it into your projects?
>
> http://ableton.github.io/link/
>
> /Daniel
> ___
> 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 GPL...

[Rui Nuno Capela]

On 09/15/2016 11:58 AM, Daniel Swärd wrote:
> Hi.
>
> Now that Ableton Link has been publically released as GPL, does anyone
> have any ideas/plans to integrate it into your projects?
>
> http://ableton.github.io/link/
>

i do (qtractor)

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