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

Paul Davis paul at linuxaudiosystems.com
Tue Nov 23 05:38:38 PST 2004


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
instances. 

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
track. 

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
	 signal.

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

--p







More information about the Ardour-Dev mailing list