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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
