[ardour-dev] issues with plugin in/out counts

[Josh Karnes]

Paul Davis wrote:
> Josh, 
> 
> thanks for your feedback. Even if I appear to be a little, ahem,
> aggressive in my response, its very valuable having the type of
> feedback you're offering, so please keep it up.

Paul, your response was not aggressive at all.  I am used to interacting 
with software developers on a daily basis and I expect that you have made 
reasoned, calculated, and informed design choices, put a lot of work into 
implementing them, and I'd expect you to defend those choices in the face of 
critique.  Only if, in your mind, the critique overwhelms your own defense 
and reason should you consider change.  I use and enjoy Ardour every day as 
it is.  No software is without design choices that fail to please at least 
some users.

> 
> 
>>The big thing Ardour is obviously missing is a channel send.

> could you be more specific about how you think it should work?

Sure :).  The send would appear on the mixer strip as a level control and 
automatically be connected to a bus.  So if there were six pre-fader 
(post-pan) sends, and four post-fader (post-pan) sends, then you'd have a 
section of the mixer strip labeled "SENDS", and below it "PRE" label beside 
six little sliders numbered 1-6, then below that four more numbered 7-10 
with the "POST" label.  What those sends do is act basically like faders to 
busses (10 of them!) that are pre-set in Ardour, and four of them are after 
the fader, all are after the panner.  This is different (better) than a 
normal mixing console where sends are mono and are before the panner (panner 
in a mixer is last in the circuit).

Somewhere else in Ardour there would then be a way to configure sends. 
Basically a "Send Editor" dialog/window.  So you can assign sends to connect 
to outputs, busses, etc., control level & pan for each send, and add 
inserts/plugins to the sends.  By default, all of the sends are connected to 
Master 1 & 2 and have no plugins.

> 
> 
>>If I could have my way and redesign Ardour, it would have mono-only inserts
>>(any x-in y-out plugins will be summed/copied input/output so they behave as
>>1-in/1-out when inserted into the pre-pan/pre-fader insert).  It would have
> 
> 
> how can you turn an x-in/y-out plugin into a 1in/1out? the other way
> around is doable via the "multi-mono" approach that we do right
> now. but i can't see how to do this the other way. 

You do it by just summing.  So if you have a 1-in/2-out plugin, then the 2 
outs are summed to one as they are inserted back into the channel.  So an 
autopanner, for example, should have no effect.  A stereo delay will become 
a mono delay.  If it's a 2-in/2-out plugin, then the same signal is applied 
to both inputs, and the outputs are summed.

I think of it more like a "Y" cable...  if you have a 1-in/2-out plugin, 
then there's an automatic "Y" cable stuck on the output to make it 1-in/1-out.

               +----------------+
               |           out-1+---+
[INS-OUT]---o-+1-in PLUGIN     |   +----[SUMMED OUTS]--o---[INS-IN]
               |           out-2+---+
               +----------------+

make sense?

> this all seems impossibly limited to me. you're basing everything on
> the notion of only mono or stereo tracks. the challenge is to make it
> easy to work with such tracks, since they are overwhelming the common
> case, but to make it also possible to work other configurations for
> experimental music, sound installations etc.

I think this could be accomplished by just laying out a way of doing other 
things that doesn't require unnecessary complexity when working with the 
most common tracks.  Like I said, using sends for example for multiple bus 
outputs, etc.  Mostly it seems like adding the flexibility for the very 
small minority of the cases makes it substantially more difficult to use in 
the overwhelming majority of cases, so it's not a worthwhile tradeoff. 
That's just my opinion!  :)

> 
> as for ganging to get stereo - this isn't an effective design at all
> unless you use explicit cabling (like you have to on a physical
> mixer). a stereo track is a different entity entirely from a pair of
> ganged mono tracks. in the signal domain they may be equivalent, but
> from the time domain (i.e. editing) perspective, they are very
> different. 

I am just suggesting this as a way of conceptually dealing with them in 
terms of the mixer gui.  Rather than just having one channel strip with two 
faders, just have a double-wide channel strip that looks like two, but the 
sends (that don't exist [yet] :), inserts, etc., are all combined (so one 
set of sends, inserts, routes, mute/solo, bus, etc...  or you press one "S" 
button and both come on).  The only thing independently adjustable is the 
panner.  The way the track is treated is exactly the same as before, just 
the presentation in the mixer is different.  Mostly I think this removes 
some ambiguity about how the panners work, and clearly identifies a stereo 
track as something different from a mono track.


> you want sends to appear in the mixer? thats not that hard to do ...

Yeah, and with level sliders.  Preferably post-pan!  Otherwise I think sends 
are nearly useless.  Having the panner after the sends requires a ton of 
duplicate plugins and excess CPU overhead to deal with them.

signal-flow-wise, then, you have:

INPUT----[INSERT]---[PANNER]--+--[FADER]--+--[INSERT]----OUTPUT
                               |           |
                          [PRE-FADER] [POST-FADER]
                              SENDS       SENDS


> i think the panner issue is caused by people not understanding how
> panning works because they haven't used ProTools ;)

Alternately, maybe they've used a regular mixer or anything other than 
ProTools.  FWIW you're right!  I've never used PT.  I came from Nuendo & 
Cubase, and of course analog mixing desks etc.


> 
> as someone else noted, if you put a 1in/2out plugin into a protools
> mono track, you convert it into a stereo track which means it has
> *two* panners. putting such a plugin into a mono track is a
> *deliberate* act - the problem is that we have to make it obvious that
> you are doing something significant when you do this (e.g. check via a
> dialog that you understand the consequence of adding or removing it).

You know, frankly, I think maybe this could be something you set in a 
configuration file.  So I can set my Ardour to do the summing as I described 
above (no 1-in/2-out stereo conversion) all the time, or I can set it to 
allow you to do this conversion thing as it currently does.  Maybe all of 
this is stuff where the user can turn off "flexibility" when it's an 
impediment to workflow and they're not going to use it.

In Nuendo, you create a project and tell it how many outputs it's going to 
have and all of the faders etc are automatically arranged in the project to 
work that way.  You'd have to go reset the global bus architecture of the 
project to reset the faders.  So when you create a "stereo" project, it's 
got everything set for only mono or stereo tracks.  If you create a "5.1" 
mix then everythig has a six-way fader that looks like a joystick.  This 
would also be doable, maybe with templates or something.  Main thing is, 
clearly it needs some kind of attention or clarification since there are so 
many folks chiming in on the topic.

> 
> if you only ever insert 1in/1out plugins on a 1in/n-out track, and
> 2in/2out plugins on a 2in/2out track, which many people would accept
> as "normal", you'd never see the panner change state. the state change
> occurs because we *allow* you to change the effective type of track
> (just like PT does) by inserting 1-in/!1-out plugins. if we deny that,
> then the panner will never change state.

Right.  I'd say that's preferable, for those of us who may do pan state 
mixing before adding or finalizing inserts.  Or in other words, I think we 
have to come up with a way that adding inserts does not change pan state.  I 
have some other thoughs on this but they don't make sense yet :)  Maybe it's 
just something to make user-configurable as a global option to Ardour.