[linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

Tim Goetze tim at quitte.de
Tue Mar 9 17:49:46 UTC 2004


[Alfons Adriaensen]

>On Tue, Mar 09, 2004 at 04:46:58PM +0100, Tim Goetze wrote:
>
>> understood. now please consider the implications for a host: it needs
>> to find the offset into the string array where the labels for the
>> first ENUMERATED port start. no problem, we use PortCount. then it
>> needs to compute how many labels (integer values inside that port's
>> range) to find out where the next port's value label enumeration
>> starts. and so on for every such port.
>> all this code needs to be written in every host, just because you
>> don't want to give fool-proof pointers to arrays terminated by a NULL
>> element? you must be kidding.
>
>Be reasonable. This is not complicated at all. See code below.

thanks for providing the code. i'll not argue it is not complete
seeing that it seems impossible to obtain ladspa.h or gcc from your
workplace. :)

without making an absolute estimate of the complexity of your snippet,
and presuming it will compile and work flawlessly, i think it is safe
to say it is more complex than the PortInfo proposal.

next, i would like you to consider that if this mechanism becomes
reality, we'll have to give a watertight explanation in the ladspa
header.

also still in dire need of explanation is the fact that an array is
referenced as 'PortNames' but contains data that will not fit this
name.

i do admit the mechanism is elegant, and makes for a compact object
file. but these are secondary virtues, with no good reason given why
they should preceed primary virtues: readability, simplicity, fool-
proof operation, versatility.

lastly, you still haven't given a good reason why non-integer values
should not be associated with labels.

amicalement,

tim

ps: i like your indentation style fwiw.



More information about the Linux-audio-dev mailing list