On Sun, Aug 09, 2009 at 04:39:01PM -0400, David Robillard wrote: > The port groups extension lets a plugin say things like "these two > outputs are a stereo pair associated with this particular mono input", > or "this port is a sidechain of this other port", etc. A big problem > with this stuff with LADSPA is that "3 audio outputs" is pretty much > impossible to make sense of (or even 2... the only reason anything > multi-channel works at all is apps make undocumented assumptions). What > ports are what, and what other ports they may correspond to, is all the > information you really need.
Not really, see below. > That said, yeah, replication for anything beyond 1 in 1 out is pretty > unlikely to make sense regardless; unless someone is using 4 outputs as > 2 stereo pairs or something like that. Ideally we'll get to the point > where the user can specify they are doing so, so the automatic logic has > more to work with. It's a bit of a weird thing to do anyway, though... Things like using 4 channels as 2 stereo pairs just shouldn't happen. Given e.g. Ardour's flexibility in creating strips with any number of channels there is no need to do such things. Just use 2 stereo strips in that case, you can link the gains if that is essential (*). > I don't think it makes sense to say whether "replicating a plugin" makes > sense or not, in general. Not the plugin's problem, in any case, the > plugin should just describe what it's I/O is. How clever the host wants > to be given that information is the host's problem (and depends on quite > a bit of host specific . For a simple 'mono' plugin there are at least three different cases to consider whem using it in a 'multichannel' situation; 1. A plugin that does e.g. EQ can be replicated without problem for multichannel use - you expect the same processing on all channels, the order doesn't matter, and the channels do not interact. 2. The situation is already different for e.g. a compressor or limiter. In that case you would expect the same gain profile on all channels, probably determined (but not always) by the one with the highest level. In other words the channels *do* interact. 3. Polyphonic synthesis is again different situation, the voices would share some control inputs but not all, and many of the voices could be 'inactive' most of the time - a case that invites some optimisation. Clearly at least (2) requires the plugin to be aware of the situation, and to be designed to handle it. That in turn is possible only if the plugin interface can represent this case. But also case (1) would benefit from being aware of the multichannel use: in many cases the bulk of the work is not the real signal processing but things like limiting the rate of change of parameters, computing and interpolating internal parameter values etc. and all of that can be shared if the plugin standard is designed for it. It's not possible to 'retrofit' this to existing mono plugins by an extension. And finally, a plugin that would do the right thing in case (2) would fail if used in case (3) - it again needs to be aware of being used in this role. The fourth multichannel case would be things like Ambisonics, where channels are not equivalent. This can be handled only by plugins designed for these type of signals. They would probably use special port types to indicate this. But at the same time a simple mono EQ could be replicated safely to process even a 16-ch AMB signal, so that should be possible even if the port types do not match, and should not require special 'AMB equalisers'. So the logic is not going to be as simple as just requiring the same port types. Building this logic on top of a set of optional extensions would seem to be a nightmare, and that is and always has been my main objection to this approach. (*) Ardour allows linking faders in groups, but it does not have 'VCA' faders - which is incredible since these are one of the most useful feauters of almost all digital (and some analog) mixers. -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
