linuxaudio.org

On Tue, 2009-08-11 at 19:01 +0100, Steve Harris wrote:

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

Sold.
> I don't remember offhand whether a float *data[] lets you dereference

quoted text
> 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[]; }

quoted text
> 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

quoted text
> 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

quoted text
> >>

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

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

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev