<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 5, 2012 at 9:28 AM, Ross Johnson <span dir="ltr"><<a href="mailto:Ross.Johnson@homemail.com.au" target="_blank">Ross.Johnson@homemail.com.au</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 6/12/2012 12:29 AM, Jörn Nettingsmeier wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/05/2012 12:32 AM, Paul Davis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
On Tue, Dec 4, 2012 at 6:03 PM, Adriano Petrosillo<br>
<<a href="mailto:ampetrosillo@gmail.com" target="_blank">ampetrosillo@gmail.com</a> <mailto:<a href="mailto:ampetrosillo@gmail.com" target="_blank">ampetrosillo@gmail.com</a><u></u>>> wrote:<br>
<br>
<br>
    User-defined channel strips, as in "you decide what to put in it",<br>
    meaning there is NO DIFFERENCE to normal Ardour operation, you still<br>
    load plugins the normal way, you still get to choose which plugins<br>
    to use, you still have your say on EVERYTHING, you just have the<br>
    OPTION (which you may want to use or not) to have some parameters<br>
    ready on a channel strip on the mixer, just like a "custom" version<br>
    of Mixbus, with your favourite plugins<br>
<br>
<br>
to repeat: done.<br>
<br>
    and a layout YOU choose to make.<br>
<br>
<br>
not done. and vastly more work than the first part.<br>
</blockquote>
<br>
well, it took me some time to see it (because i found some of the OP's remarks a bit offensive) but i think here adriano is pointing into a very interesting direction:<br>
<br>
auto-swallowing a gui into a channel strip is next-to-impossible, like paul explains. but adriano talks about customizable: the user gets to decide the layout and what's to be included in the strip, i.e. s/he has to do all the hard work, not the software. good solution from a programmer's POV, and from a user experience POV :)<br>

</blockquote>
<br></div>
Perhaps there are better ways today but I like what several/many/(most?) hardware digital consoles do, which is to use a single FX control/display panel on the desk and a select button on each track or buss or master strip to bind the whole panel to that strip until another strip is selected. </blockquote>
<div><br>adriano, this is pretty funny.<br><br>somewhere near the top of this thread you were arguing that the limitations of hardware consoles shouldn't be propagated into software.<br><br>the primary reason that this design exists is because it is cheap - much, much, much cheaper than per-strip controls. it is a limitation that exists to sell more gear, because without it, the gear would cost too much.<br>
<br>that said, the so-called "fat channel" approach used by several console makers, in which the strip has a full set of controls BUT the "fat channel window" has even more, does have its merits. however, those merits mostly come from the existence of a fixed set of defined "plugins" (builtin DSP) that are mapped into that window.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The DAW equivalent would be a separate window or frame where a single instance of each plugin type in use in the session appears, and all plugins therein display only the settings for the strip that is currently selected. If the selected strip doesn't use one or more or any of the plugins then those simply appear as by-passed.<br>

<br>
I assume that pre and post fader plugins are still possible in Ardour in which case either have a separate pre and post FX panel and one strip select button, or one panel and separate pre and post select buttons per strip. The former would probably work better IMO.<br>

<br>
That way track strips don't need to swallow plugin guis or create havoc with layout, plugin guis [for the track of interest] can remain visible at all times, and CPU cycles are kept to a minimum because only one strip is having it's plugin parameter and dynamic elements displayed and updated in real-time.</blockquote>
<div><br>sounds conceptually a lot like the route inspector from a2. this was dropped because of a variety of reasons.  it provides a single window that can be used to display plugins, i/o routing and more for each track/bus. it could be resurrected in a somewhat different form.<br>
</div></div><br></div>