14 Aug
2009
14 Aug
'09
9:36 p.m.
On Fri, 2009-08-14 at 23:41 +0100, Steve Harris wrote:
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
On 14 Aug 2009, at 21:47, David Robillard wrote:
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.
The host can do it automatically, obviously.
The host can do it automatically with the C multiplication operator as
well, obviously. 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.