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

Steve Harris steve at plugin.org.uk
Tue Aug 11 18:01:13 UTC 2009


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



More information about the Linux-audio-dev mailing list