11 Aug
2009
11 Aug
'09
5:55 p.m.
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.
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.
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?
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.
- Steve