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

[Christopher K. George]

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

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
ardour's task.

Interesting: The user could create feedback loops unless somesort of
constraint was added.

~ckg




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
> 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
> 
> _______________________________________________
> ardour-dev mailing list
> ardour-dev at lists.ardour.org
> http://lists.ardour.org/listinfo.cgi/ardour-dev-ardour.org