Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
From: Tim Goetze (tim_AT_quitte.de)
Date: Tue Mar 09 2004 - 17:46:58 EET
[Alfons Adriaensen]
>On Tue, Mar 09, 2004 at 02:46:47PM +0100, Tim Goetze wrote:
>> [Alfons Adriaensen]
>
>> >I think that in a case like this, you will always be able to map the
>> >'important points' to integers.
>
>> ok. since we don't have any code to base our judgement of this
>> proposal on, i'll quote an earlier post from you, where you are
>> referring to the strings describing specific parameter values:
>
>1. I assume that everybody on this list knows what what an array
> of string constants looks like in C. Otherwise, see ladspa.h.
> It's the same array, it only becomes longer. That's all there is
> to it, there no further 'code' required.
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.
besides, on the plugin side you end up with a potentially huge array
of mostly unrelated strings, where index ordering and number is vital.
a welcome feeding place for bugs here, too.
i haven't seen such complicated data structuring practice since the
days of machine-language coding only. it reminds me more of a binary
file format spec than of a public API intended for general use.
>2. I fail to see the relation between the remark you quote, and your
> comments below.
agreed, a case of bad quoting on my part. i was referring to the
consequences of your proposal, assuming they are clearly implied.
now that i have stated them, the relation becomes a little clearer
i hope.
>> this _is_ a dirty trick and an ad-hoc solution if ever there was one
>> if you ask me. generalizing this to higher levels gives me nausea.
>
>Grouping all strings into a 'string pool' with some indexing scheme on
>top is a very common idiom. See most object or library file formats,
>symbol table algorithms, etc.
a string pool is ok per-se (although it's not an idea i prefer for
reasons already given), but certainly not one referenced by the name
'PortNames'.
i'm also clearly against requiring plugin and host coders to be
knowledgeable in compiler and binary object format implementation
and techniques. you can be glad if DSP people speak more than BASIC
to start with. :)
[...]
>The order they are put in corresponds to a breadth-first traversal
>of this tree. This is one of the standard algorithms to index tree
>elements (the two other commonly used are depth-first and in-order).
>It has the advantage (in this case) that elements are sorted by level,
>so the portnames remain where they are now.
whatever fancy name you choose to give it, it's still at least a hack
and certainly the wrong place to put it to me. :)
vriendelijk,
tim
This archive was generated by hypermail 2b28 : Tue Mar 09 2004 - 17:52:55 EET