<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Paul,<br>
<br>
Just to let you know, the email you're responding to here wasn't
from Adriano. But I'll respond to one point anyway...<br>
<br>
On 6/12/2012 1:39 AM, Paul Davis wrote:<br>
</div>
<blockquote
cite="mid:CAFa_cKn6qqYovMS5BU5TZc-DpU37Rx+3rXSJxZMhA1d5YJ8gRg@mail.gmail.com"
type="cite"><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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:ampetrosillo@gmail.com" target="_blank">ampetrosillo@gmail.com</a>
<mailto:<a moz-do-not-send="true"
href="mailto:ampetrosillo@gmail.com" target="_blank">ampetrosillo@gmail.com</a>>>
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>
</div>
</div>
</div>
</blockquote>
<br>
I prefer to imagine they took advantage of the technology to reduce
costs so that more people could access more sophisticated consoles.
:-)<br>
<br>
IMO the end result is ergonomically just as efficient once you've
used it enough, and automation has reduced the need for "many hands"
on the console to perform mixes. In today's one DAW-one operator
world if you need many hands then network and sync many DAWs and
operators together.<br>
<br>
<blockquote
cite="mid:CAFa_cKn6qqYovMS5BU5TZc-DpU37Rx+3rXSJxZMhA1d5YJ8gRg@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<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>
</blockquote>
Sounds promising.<br>
<br>
Regards.<br>
Ross<br>
<br>
</body>
</html>