11 Aug
2009
11 Aug
'09
4:01 p.m.
On 11 Aug 2009, at 18:41, David Robillard wrote:
It's more intune with typical DSP code too.
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.
You might actually want a struct of { int channels; float *data[]; }
though to keep all the pertinent stuff together.
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.
Yeah, a little painful to handle, but a utility function can sort it
all out.
- Steve
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. 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.