11 Aug
2009
11 Aug
'09
8:12 p.m.
On Tue, 2009-08-11 at 20:54 +0100, Steve Harris wrote:
I'd be tempted not to shoot for back compat here. It's hard to see
where there's a clear win over just having two plugins, with
a :isMutliChannelVersionOf predicate or similar, so the host can pick
the right one intelligently.
Meh, I'm thoroughly sick of multiple versions of the same plugin.
Control vs audio is next against the wall :)
It's probably straightforward to make it so that plugin authors can do
it however they want, anyway.
Well, you'd end up checking the number of channels stored in the
plugin's data anyway, having a case where it's just a plain old buffer
doesn't seem to be that much of an additional nuisance (and the win is
massive).
Is the win massive?
I see a great deal of existing plugins that would make sense to
replicate, so I would say yes.
True. Just a thought.
-dr
On 11 Aug 2009, at 20:09, David Robillard wrote:
Yes, actually if it has to be the same on all then giving it the
oportunity not to be is not ideal, but if it /can/ vary then it's
conceptually best to have it close by, IMHO.
Agreed. It's probably best to allow it to vary. I suspect that
different groups of ports varying separately will be needed by larger
plugins. Some have synthesis sections and effects sections, or multiple
'mixer strips' and the like, for example.
You might
actually want a struct of { int channels; float *data[]; }
though to keep all the pertinent stuff together.
Good point... this also sets things up to be compatible with
plugin-allocated dynamic output buffers in the future without needing
any hokey mechanism just to say how many are there, which can't hurt.
Maybe we should go a teeny bit further and make the struct extensible,
putting the data pointer first.
Slight overhead in that the number of channels may be shared between
many ports, though. Is it possible to specify that a port is both a normal
LADSPA Audio
port, and a magic multichannel port? If not the back compat thing
is a
deadend anyway.
I think the port would probably have to be of the MultiPort type, then
either 1) also of another data type, or 2) have a :contentType
predicate
to point to that other type. We certainly don't want a combinatorial
explosion of multi-types. Probably 2) is needed for backwards
compatibility, but I forget the details of the spec here... Backwards
compatibility is one reason a big multi-buffer (the first
part
of which is a single normal buffer) might be good. Though there can
just be a rule something like "if the host doesn't support
multi-buffers, the plugin must expect a single buffer", which seems
fine.
Yeah, a little painful to handle, but a utility function can sort it
all out. P.S. extension
and LV2 in general discussions are much more active
here
than lv2-dev. I wonder about the benefit of it existing at all...
Well, stuff that gets discussed there tends to be a bit more indepth.