[Ardour-Users] a few thoughts

Ross Johnson Ross.Johnson at homemail.com.au
Wed Dec 5 07:45:17 PST 2012


Paul,

Just to let you know, the email you're responding to here wasn't from 
Adriano. But I'll respond to one point anyway...

On 6/12/2012 1:39 AM, Paul Davis wrote:
>
>
>
> On Wed, Dec 5, 2012 at 9:28 AM, Ross Johnson 
> <Ross.Johnson at homemail.com.au <mailto:Ross.Johnson at homemail.com.au>> 
> wrote:
>
>     On 6/12/2012 12:29 AM, Jörn Nettingsmeier wrote:
>
>         On 12/05/2012 12:32 AM, Paul Davis wrote:
>
>
>
>
>             On Tue, Dec 4, 2012 at 6:03 PM, Adriano Petrosillo
>             <ampetrosillo at gmail.com <mailto:ampetrosillo at gmail.com>
>             <mailto:ampetrosillo at gmail.com
>             <mailto:ampetrosillo at gmail.com>>> wrote:
>
>
>                 User-defined channel strips, as in "you decide what to
>             put in it",
>                 meaning there is NO DIFFERENCE to normal Ardour
>             operation, you still
>                 load plugins the normal way, you still get to choose
>             which plugins
>                 to use, you still have your say on EVERYTHING, you
>             just have the
>                 OPTION (which you may want to use or not) to have some
>             parameters
>                 ready on a channel strip on the mixer, just like a
>             "custom" version
>                 of Mixbus, with your favourite plugins
>
>
>             to repeat: done.
>
>                 and a layout YOU choose to make.
>
>
>             not done. and vastly more work than the first part.
>
>
>         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:
>
>         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 :)
>
>
>     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. 
>
>
> adriano, this is pretty funny.
>
> somewhere near the top of this thread you were arguing that the 
> limitations of hardware consoles shouldn't be propagated into software.
>
> 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.

I prefer to imagine they took advantage of the technology to reduce 
costs so that more people could access more sophisticated consoles. :-)

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.

>
> 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.
>
>     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.
>
>     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.
>
>     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.
>
>
> 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.
>
Sounds promising.

Regards.
Ross

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-users-ardour.org/attachments/20121206/8f9901af/attachment-0002.htm>


More information about the Ardour-Users mailing list