<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 7, 2013 at 10:32 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 Sat, Sep 07, 2013 at 09:48:43AM -0400, Paul Davis wrote:<br>
<br>
> On Sat, Sep 7, 2013 at 5:56 AM, Fons Adriaensen <<a href="mailto:fons@linuxaudio.org">fons@linuxaudio.org</a>> wrote:<br>
><br>
</div><div class="im">> > 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>
> ><br>
><br>
> Nope. There are no changes (so far) to the semantics of ports and wiring<br>
> arising from this change. The goal was to make "native" audio I/O possible<br>
> (i.e. non-JACK), not to alter the basic port model that Ardour has<br>
> inherited from JACK (and that in some senses JACK originally inherited from<br>
> Ardour).<br>
<br>
</div>The context of my question above, which maybe wasn't clear, is<br>
'when not using Jack, but a native interface, if and when that<br>
will be possible'.<br></blockquote><div><br></div><div>that was the context of my answer as well. again, nothing about the changes made thus far alter the basic usage of ports by ardour.<br></div><div> <br></div></div>
</div></div>