On Fri, 2009-08-14 at 23:41 +0100, Steve Harris wrote: > On 14 Aug 2009, at 21:47, David Robillard wrote: > >> > >> The host can do it automatically, obviously. > > > > The host can do it automatically with the C multiplication operator as > > well, obviously. > > True, but irrelevant. > > If you have N channels feeding a panner with 5.1 outs v's N channels > feeding 2.1 outs, I very much doubt that you want that to be a single > plugin.
It has to be, because the N channels may be a specific type of N channels. 7.1, say, or ambisonic. > Ambisonics may well be different, but my understanding is that there's > a selection of different formats, and you don't go between them by > just adding or removing channels. Exactly. You can't use N 1->M panners to do an N->M panning job. This is true of *.1 as well as ambisonics. In general, this is just the ugly head of a huge shortcoming LAD stuff has always had, the LADSPA and JACK assumption that just having a "bunch of channels" is not good enough. If you think about it, it's actually pretty true to say that the LAD/Jack/LADSPA stack doesn't even correctly support stereo! We get by with undocumented assumptions about port order and such. I'd have a hard time saying anything beyond stereo is reasonably supported at all. Sure, you can carefully wire up everything manually, but the shortcomings there are obvious. Time to fix that oops. > > Surround panning is not trivial, and not a small amount of code. It > > is > > exactly the sort of thing you'd want a plugin for. > > Agreed. I still don't know how you'd make it work though. I don't think it's really that bad, or much worse. Instead of the API allowing the host to say "plugin, you have N channels", the API allows the host to say "plugin, this group has N channels". On the data side of things, all we really need is the before discussed predicates to say this group's count matches that group's count, and a predicate to list supported 'stream types'. I could be missing something? It doesn't seem that much more complicated. It /could/ be quite a bit more complicated if, say, the host set the input counts and the plugin could dynamically say pretty much anything about the output counts, but I agree /that/ would probably be going too far. I don't think that is really needed, being able to say this group and that group are equivalent seems to take care of anything even remotely feasible in the short to medium term. Equivalence is pretty easy to deal with, and the simple plugins (that are the arguments for a global count) would only have 1 input and 1 output group that would match anyway. The simple plugin case is pretty much as easy to deal with as it is if the spec only supported a single count. Common host logic would be something like: - I have a stereo stream here for this plugin - Does this plugin support stereo input? - If yes, then set the plugin inputs to stereo, and check what outputs are matched (trivial), and set those to stereo too - If no, this plugin doesn't work here (defer to user or just reject) There are annoying cases that could crop up, such as the outputs already being connected to something non-stereo, but these would have to be dealt with either way. It seems to be having the count at the group level doesn't really complicate anything much. Cheers, -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
