Re: [LAD] Lv2 port replication [was Re: the role of lv2 extensions]

On 11 Aug 2009, at 18:41, David Robillard wrote:
>
>> 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.

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.

>> 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.

Yeah, a little painful to handle, but a utility function can sort it
all out.

- Steve
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Aug 12 00:15:04 2009