On 11 Aug 2009, at 20:09, David Robillard wrote:
>> 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.
Yes, actually if it has to be the same on all then giving it the
oportunity not to be is not ideal, but if it /can/ vary then it's
conceptually best to have it close by, IMHO.
>> 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...
I'd be tempted not to shoot for back compat here. It's hard to see
where there's a clear win over just having two plugins, with
a :isMutliChannelVersionOf predicate or similar, so the host can pick
the right one intelligently.
>>> 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).
Is the win massive?
> 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...
Well, stuff that gets discussed there tends to be a bit more indepth.
- 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:06 2009
This archive was generated by hypermail 2.1.8 : Wed Aug 12 2009 - 00:15:06 EEST