On Sun, 2009-08-09 at 23:41 +0200, Fons Adriaensen wrote: > On Sun, Aug 09, 2009 at 04:39:01PM -0400, David Robillard wrote: > > 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.
I agree. > > I don't think it makes sense to say whether "replicating a plugin" makes > > sense or not, in general. [...] > 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. This is a good point I hadn't thought of. I think I will try to incorporate this into the port groups extension (it describes how channels interact, and basically anything else to do with multi-channel, so it more or less belongs there...) > 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. Actually I would say this is exactly the same as situation 2, in terms of I/O at least (e.g. active/inactive optimisation can be done inside the (opaque) port contents, or similar, and must be anyway since it's not necessarily related to dymamic number of channels) > 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. This is dramatically more complicated than the simple cases for replication. It is possible though, and very similar to what's needed for true polyphony. Different scope though (i.e. involves a bunch of binary stuff and severe design changes), see above about can of worms. Most importantly, the information needed for the simple cases is needed in any case (including ones that have nothing whatsoever to do with replication... we need to know what the heck our plugins outputs are!). In short what's needed is ports that can actually hold several buffers, (where the number of which is dynamically configurable). I've actually been planning on this one for a while because "hidden" (mixed down) polyphony sucks severely in a modular, but never thought of it in terms of replication. Interesting that it applies there too. > 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. Currently handled. Not special ports, just collections of normal ports with appropriate metadata (as it should be). > 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'. Yep. That kind of clever is up to the host though (or maybe proxy plugins if you want to get really fancy, but let's not go there) > So the logic is not going to be as simple as just requiring the > same port types. No, but the information needed to solve the simple ladspa+metadata-esque case is required anyway, and an orthogonal problem. Solving small independent problems is good. Trying to solve everything at once fails. Always. No exceptions. To be clear, what I mean is: first and foremost, the host must know the specifics of what ports are what. On top of this, dynamic replication of ports can be done. That said, one question comes to mind: are there reasonable cases where different ports (or groups of ports) need different 'replication factors'? > 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. FUD, nothing more. It would be no more of a nightmare than implementing it on top of... well, anything else; presumably you mean something defined in "The LV2 Specification"(TM). No offense but I doubt you really understand the mechanism judging by this comment. That "nightmare" (a.k.a. "good design") is exactly what will allow all of the above to be solved. Proof is in the pudding, as they say. ----- Aside: Since this seems to be misunderstood frequently, I'll harp on the point a bit for the list in general (this is an explanation, not an invitation to argument): There is absolutely nothing second class, or (necessarily) optional, about LV2 extensions. A lot of thought has been put in to the extension/feature concept/mechanism, and it has been carefully designed specifically so that it is not a "nightmare". Solving the above problems in "extensions" is not worse than if we were to ram it into the "core" spec itself. There is nothing inferior about it (wannabe dictator arguments aside, anyway). There are many things superior about it, however. The most important is social: nobody on this list needs to be convinced that having one specification define absolutely everything is a sure-fire way to have any potentially productive discussion devolve into endlessly long threads that end up nowhere because nobody can agree on what's "needed" and what isn't. Extensions are simply a modularisation of this process: problems can be solved independently by people who care about those particular problems. You can even work on actual implementations of things to test them out without any compatibility problems whatsoever. So, we have nice tidy little tractable problems, that can feasibly be solved well (see: UNIX). The end result is: the problems actually, really, can get solved. Saying this is bad is essentially equivalent to saying design by committee is good... modularisation like this is such a universally recognized good design principle it's not really necessary to defend it. UNIX won, and it's not a coincidence. GMPI has produced almost nothing tangible of worth whatsoever, while LV2 has produced plenty and is constantly getting better -- this is not a coincidence either. Mmm, pudding. Cheers, -dr P.S. To reply to the aside, please change the subject, I don't want to derail the replication discussion; that is an important unsolved problem _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
