[ardour-dev] issues with plugin in/out counts (longish)
gml at xs4all.nl
Fri Nov 26 15:46:44 PST 2004
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
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
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
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
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.
|| 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.
electronic & acoustic musics-- http://www.xs4all.nl/~gml
More information about the Ardour-Dev