On Tue, 2009-08-11 at 19:01 +0100, Steve Harris wrote:
> 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
> 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.
>
> 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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Aug 12 00:15:05 2009
This archive was generated by hypermail 2.1.8 : Wed Aug 12 2009 - 00:15:05 EEST