Re: [LAD] aBLETON lINK

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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