<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 7, 2013 at 5:56 AM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org" target="_blank">fons@linuxaudio.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Sep 06, 2013 at 01:48:01PM -0400, Paul Davis wrote:<br>
<br>
> Specifically, it removes the explicit use of JACK from the codebase -<br>
> instead, JACK support is just another shared library that ardour can load<br>
> if the user requests it. It is now technically possible to create different<br>
> audio backends for Ardour that speak directly to the OS' underlying native<br>
> audio API (e.g. ALSA or CoreAudio), though the work involved in this is not<br>
> trivial. The work was done at the request of a commercial partner who plan<br>
> to provide various backends.<br>
<br>
</div>So that means that you would connect a track input to e.g.<br>
'input 17' using Ardours's connection dialog, instead of<br>
having a 'port' with a dedicated name (the track's name) ?<br></blockquote><div><br><br></div><div>Nope. There are no changes (so far) to the semantics of ports and wiring arising from this change. The goal was to make "native" audio I/O possible (i.e. non-JACK), not to alter the basic port model that Ardour has inherited from JACK (and that in some senses JACK originally inherited from Ardour). <br>
<br>Changes like that might or might not happen later. <br></div><div> <br></div></div></div></div>