[ardour-dev] issues with plugin in/out counts
Christopher K. George
ckg at YaleSDA.org
Tue Nov 23 08:10:38 PST 2004
Yes, I agree that too much is trying to be controlled with too little.
Currently plugins are handled as a consecutive flow but, because of ardour's
great flexability, knowing how to handle the interconnects between each
segment (plugin) automatically, without limiting ardours flexability, is
I understand that more complex routing can be done with busses, but I agree
that providing a graphical dialogue where inputs and ouputs can be routed
would be very useful and much more intuitive to the user. Here's what I envision.
Ardour has n channels going into the pluging complex, and the user can control
how many (m) outputs come out. (Ardour can make a good guess in many
situations, but the user has ultimate control.) The user is provided with a
graphical interface of blocks with nodes representing plugins and their inputs
and outputs. The user draws/edits the interconnects as desired. I created a
simple example at http://www.yalesda.org/plugin.png.
This sort of flexability would naturally lead to another set of functions:
channel spliting and summing with gain control on the inputs and outputs.
This could be handled by special plugins (included with ardour), simplifying
Interesting: The user could create feedback loops unless somesort of
constraint was added.
On Tue, 23 Nov 2004 08:38:38 -0500, Paul Davis wrote
> in the last few days, i've been staring down some of the problems
> people have reported when using plugins that change the number of
> active streams in a track (e.g. a 1in/2out reverb).
> my conclusion after all this work is that ardour's noble attempt to
> allow users to use plugins in the most convenient way is doomed to
> failure. for a long time, ardour has allowed a user to use a mono
> plugin in a track with stereo inputs, for example. it does this by
> replicating the mono plugin, and making the plugin GUI control both
> for the simple case, this works very very well and i think is a
> welcome feature.
> the problem is that it rapidly leads to untenable situations.
> consider what happens if you add a mono plugin to a track with 1
> input. The plugin is not replicated - there is no need to. so far,
> so good.
> now the user wants to add a 1in/2out plugin, for example most
> reverbs. no problem still, as long as they are ordered in the same
> order as they were added.
> but now the user moves the 1in/2out plugin before the 1in/1out
> plugin. all of a sudden, 1 of the outputs of the reverb is being
> thrown away, and in addition, it becomes unclear how many active
> streams the track has: does it have 2 (the number coming out of the
> reverb) or 1 (the number coming out of the gate)? this number is
> important because it determines how many panners there are for the
> after much rumination, i conclude the following: the problem is hard
> in a deep, possibly NP-complete way. we have 2 constraints that we
> need to satisfy:
> a) the inputs to plugin N+1 matches the outputs of plugin N
> to avoid throwing a signal away or using an undefined
> b) there must be an unambiguous answer to the question "how
> many active streams does a track (or bus) have?". this
> implies constraints on the number of outputs of 1 or
> more plugins to avoid an ambiguous situation like
> the one described above.
> this pair of issues creates a complex constraint system that requires
> back- and forward propagation, and reminds me of systems that are
> capable of oscillation without limit.
> the obvious conclusion from all this is to do what PT does, and
> require that mono tracks get mono plugins, etc. this still doesn't
> really answer the question entirely however, because what is a mono
> plugin? 1in/1out? how do you put a reverb into a mono track, then?
> can there ever be a 1in/2out plugin at all?
> so, folks: discuss ...
> ardour-dev mailing list
> ardour-dev at lists.ardour.org
More information about the Ardour-Dev