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