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

[vanDongen/Gilcher]

On Friday 26 November 2004 16:17, Mark Knecht wrote:

> Fair enough, as long as the sophisticated solution implemented to make
> 2% of the people happy doesn't cause problems or wated time for 98% of
> the people.
>

Actually, I think that we are sort of in agreement about this, except that I 
generalized the ProTools concept to N-channels and mentioned some 
conveniences that may or may not be necessary and that are design decisions.
There is also a need for a better indication in the gui about the internal 
routing in a track/bus.

What I think should happen is:

Looking at a route (to use the old term for track and bus in ardour),
you start at the top. (Read in mono-spaced font)
That gives a number of input streams. : |  |  |  |   , 4 in this case
(it could be anything including 0)

you can add a 4->3 plugin               |  |  | /
                                        |  |  |

now you try to add a 2->5 plugin:       |  |  ??   

Here I see the following options:
-ardour gives an error/warning message,
this can either say "we won't do it because ...", 
or it can say "what do you want to do with the extra input". 
I am actually a little bit in favor of the first. Because how you want to mix 
your three channels to 2 inputs should be so flexible that you need a panner 
for each stream at this point.

Which leads to a third way of dealing with this, explicitly put a panner in 
the gui between the 2 plugins.
BTW a panner is a pan-control for each stream, not a single control.
This is the point where it is an interface design decision.
Which will clutter up the  workspace more, multiple panners implying a 
scrolling plugin box, or forcing the user to use a separate bus over a send?

I think as a user I would go for a send in this case. A stereo send.
But that does mean that I want ardour to have pan controls working in 
multichannel sends!
And they should be automatable, and the send-level should also be automatable. 
And it should be possible to link the panning to the master panning at the 
bottom of the strip. But wait, that is difficult, because then we may a 
different number of channels (for instance if this route, that is sending a 
stereo-mix of a three channel stream to a bus, outputs into a surround 
mastering bus.)

So the linking of the panning should only be possible if the send has the same 
number of channels as the outputs of the route. Or use some configuration 
methodology to loosely couple similar objects in a meaningful way. That 
sounds like constrained based editing, but then for mixing desk 
configuration. So that is definitely for ardour-V3.

Back to my route,


I still have 3 streams here, because I couldn't insert my 2 channel plugin

                           |  |  |  


No I add a mono plugin.
1->1 plugins are a special case.
This adds three copies of the plugin as "extensions" of the outputs of the 
previous node. You never have assigment problems with 1->1 plugins, 1 divides 
all numbers.
You only have memory creation and deletion logic if the stream count changes.
This is the basic multi mono model used by protools.
So now we still have 3 streams
                           |  |  |

And finally a stereo compressor with side chain
                           |  | /

This is all sensible and easy to follow if you keep track of the channel 
counts of your plugins.

What annoys people is that if the move the order around, their panning states 
disappear.
That is because this logic requires to start at the top and move down the 
strip to discover the final pan-requirements each time a plugin is reordered 
or added and the number of streams ending up on the bottom can change.
The panning state at the bottom should however only change in this case, ( or 
when the number of outputs change) not when I move the eq above the reverb.
i.e. from 
|       |
||   to |
||      ||


I think this covers both the simple mono-stereo cases and the complex 
ambisonic to weirdo soundfield granulation cases. 
It should also be fairly straight forward to implement. Maybe some consistency 
checking when selecting a plugin to add, so you can only select possible 
plugins? The other ones should be listed though, but greyed out.
Reordering can only be done one at a time, so the problem is not that hard. It 
is not like solving a random reshuffle of a large number. It is a bit like 
rubics cube, describing a single solution is a big problem if possible at 
all, a procedural solution works much better, and anybody can learn how to 
solve the cube with it. (I know that that is how I did it)


Also I belief that when good design makes complicated things manageable, it 
will make the simple things very easy.

Gerard
-- 
electronic & acoustic musics-- http://www.xs4all.nl/~gml