11 Aug
2009
11 Aug
'09
5:09 p.m.
On Tue, 2009-08-11 at 19:01 +0100, Steve Harris wrote:
Yeah, a little painful to handle, but a utility function can sort it
all out.
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).
-dr
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...
On 11 Aug 2009, at 18:41, David Robillard wrote:
It's more intune with typical DSP code too.
Sold.
i keep thinking about arrays. passing an array of
outputs to
connect to
the plugin's inputs. null terminated array ( but this would require a
new connect() method in the lv2core, which probably is a bad
solution ).
The connect method takes a void* pointer, so this is fine. You can
stick whatever kind of data you want in ports without needing a new
connect method.
The question here is probably: array of pointers to buffers, or one
big
multi-buffer? The former is probably more flexible. I don't remember offhand whether a float *data[]
lets you dereference
as data[chan][samp] or not, but that would be nice if it's possible.
Probably not (it would actually be void* anyway), but the header can
provide a nice inline function for this.
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...
example: a DC offset removal plugin for a stereo
stream
instead of specifying 'in_left' and 'in_right', we just have
'in'.
the 'in' port is specified with portReplicable (or some such). as the
plugin is operating on a stereo stream, two ports are created 'in0'
and 'in1' (or in1 and in2), then these ports are connected as usual.
the plugin needs to discover if the host supports portReplicable???
if
the host does not support it, it will do things the old fashioned
way -
and there'd be two plugins for left + right - so the plugin will know
because the host will give it the number of channels to process.
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.