21 Sep
2016
21 Sep
'16
12:24 p.m.
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&t=14913
here's the same thing I posed on LAD
http://linux-audio.4202.n7.nabble.com/ableton-link-and-live-tempo-changing-…
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.
21 Sep
21 Sep
2:36 p.m.
New subject: aBLETON lINK
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
4:39 p.m.
New subject: aBLETON lINK
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
22 Sep
22 Sep
9:34 a.m.
New subject: aBLETON lINK
On 09/21/2016 11:24 AM, Perry Nguyen wrote:
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
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 
4:16 p.m.
New subject: aBLETON lINK
On Thu, Sep 22, 2016 at 2:34 AM, Patrick Shirkey <pshirkey(a)boosthardware.com
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).
7:32 p.m.
New subject: aBLETON lINK
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 <tito.01beta(a)gmail.com>
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 &optional 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.66666666666667d0
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 30000.0d0 30000.0d0 30000.0d0
30000.0d0 30000.0d0 30000.0d0 30000.0d0 30000.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
7:49 p.m.
New subject: aBLETON lINK
On Thu, Sep 22, 2016 at 12:30 PM, Tito Latini <tito.01beta(a)gmail.com> wrote:
On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis
wrote:
[...]
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.
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.
11:29 p.m.
New subject: aBLETON lINK
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.
11:36 p.m.
New subject: aBLETON lINK
On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini <tito.01beta(a)gmail.com> wrote:
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.
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.
On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul Davis
wrote:
across a network? with multiple tempo masters?
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.
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.
23 Sep
23 Sep
11:43 a.m.
New subject: aBLETON lINK
On Thu, Sep 22, 2016 at 04:36:17PM -0500, Paul Davis wrote:
On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini
<tito.01beta(a)gmail.com> wrote:
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.
On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul
Davis wrote:
across a network? with multiple tempo masters? The innovation is defining an API and protocol
based on 3 concepts:
tempo synchronization
an integral to get the position with the new bpm
3:56 p.m.
New subject: aBLETON lINK
On Fri, Sep 23, 2016 at 4:42 AM, Tito Latini <tito.01beta(a)gmail.com> wrote:
On Thu, Sep 22, 2016 at 04:36:17PM -0500, Paul Davis
wrote:
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?
On Thu, Sep 22, 2016 at 4:27 PM, Tito Latini
<tito.01beta(a)gmail.com>
wrote:
On Thu, Sep 22, 2016 at 12:49:42PM -0500, Paul
Davis wrote:
across a network? with multiple tempo masters? The innovation is defining an API and protocol
based on 3 concepts:
tempo synchronization
an integral to get the position with the new bpm
22 Sep
22 Sep
7:58 p.m.
New subject: aBLETON lINK
On 09/22/2016 07:30 PM, Tito Latini wrote:
On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis
wrote:
[...]
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
> 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.
11:30 p.m.
New subject: aBLETON lINK
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.
23 Sep
23 Sep
7:50 a.m.
New subject: aBLETON lINK
On 09/22/2016 07:30 PM, Tito Latini wrote:
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
On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul
Davis wrote:
[...]
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.
Ableton
have now done that, albeit by circumventing the hardest parts
of
> the problem (a tempo map with varying meter and tempo).
4:01 p.m.
New subject: aBLETON lINK
On Fri, Sep 23, 2016 at 12:50 AM, Patrick Shirkey <
pshirkey(a)boosthardware.com> wrote:
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).
On 09/22/2016 07:30 PM, Tito Latini wrote:
Only for Professional Audio. There are plenty of examples of Open Source
projects leading the field in other markets.
On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul
Davis wrote:
[...]
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.
> 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.
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?
5:12 p.m.
New subject: aBLETON lINK
On Fri, Sep 23, 2016 at 12:50 AM, Patrick Shirkey
<
pshirkey(a)boosthardware.com> wrote:
is
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).
If this is correct the trick appears to be having strong brand awareness
and releasing the API on github?
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 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 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?
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
5:19 p.m.
New subject: aBLETON lINK
On Fri, Sep 23, 2016 at 10:12 AM, Patrick Shirkey <
pshirkey(a)boosthardware.com> wrote:
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?
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?
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.
11:46 a.m.
New subject: aBLETON lINK
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
1 p.m.
New subject: aBLETON lINK
On Thu, 2016-09-22 at 19:58 +0200, Robin Gareus
wrote:
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
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?
1:22 p.m.
New subject: aBLETON lINK
On Fri, 23 Sep 2016 13:00:08 +0200, Patrick Shirkey wrote:
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
On Thu,
2016-09-22 at 19:58 +0200, Robin Gareus wrote:
Some us us disagree that this IS the "whole point" of Link. 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? 
2:55 p.m.
New subject: aBLETON lINK
"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 <pshirkey(a)boosthardware.com
--
Louigi Verona
http://www.louigiverona.com/
wrote:
On Thu, 2016-09-22 at 19:58 +0200, Robin Gareus
wrote:
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
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?
4:06 p.m.
New subject: aBLETON lINK
On Fri, Sep 23, 2016 at 6:00 AM, Patrick Shirkey <pshirkey(a)boosthardware.com
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)
5:03 p.m.
New subject: aBLETON lINK
On Fri, Sep 23, 2016 at 6:00 AM, Patrick Shirkey
<pshirkey(a)boosthardware.com
One can draw reasonable conclusions based on the evidence at hand.
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.
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
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)
5:13 p.m.
New subject: aBLETON lINK
On Fri, Sep 23, 2016 at 10:03 AM, Patrick Shirkey <
pshirkey(a)boosthardware.com> wrote:
> > > 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.
One can draw reasonable conclusions based on the evidence at hand.
You don't have any evidence other than the absence of evidence.
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.
Aawwwwww .... 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.
5:55 p.m.
New subject: aBLETON lINK
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.
8:51 p.m.
New subject: aBLETON lINK
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.seeber(a)spectralbird.de> wrote:
On 09/23/2016 05:13 PM, Paul Davis wrote:
--
Louigi Verona
http://www.louigiverona.com/
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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
8:59 p.m.
New subject: aBLETON lINK
On Fri, Sep 23, 2016 at 1:51 PM, Louigi Verona <louigi.verona(a)gmail.com>
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.
30 Sep
30 Sep
4:04 p.m.
New subject: aBLETON lINK
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
13 Oct
13 Oct
8:37 p.m.
New subject: re
On Fri, September 30, 2016 16:04, David Robillard wrote:
(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)
Why is it weird?
last time (sometime ago) the installer exe was presenting itself like a
regular installer that was not unlike others. i'm not sure to remember if
there was also another tool required (asio4all / ?) to make it work or
not. compared to what jack already offers including it's ecosystem it
seems a small step to make the installation on other platforms something
that can be looked at as "solved". if there are issues, they could be
addressed. it should be easy for anyone designing their audio tools on top
of jack to rely on a basic plate that's offering a "working" jack.
greetings
Thomas
2751
days inactive
2773
days old
linux-audio-dev@lists.linuxaudio.org
29 comments
12 participants
participants (12)
-
Daniel Swärd -
David Robillard -
Louigi Verona -
Markus Seeber -
Patrick Shirkey -
Paul Davis -
Perry Nguyen -
Ralf Mardorf -
Robin Gareus -
Rui Nuno Capela -
Thomas Brand -
Tito Latini