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

[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.

2. I fail to see the relation between the remark you quote, and your
   comments below.


> >Appending the labels to the port names array looks very clean to
> >me. The array becomes in effect an array that contains all strings
> >required - first the top level ones (port names), then the second
> >level (enum labels). This is not a dirty trick or an ad-hoc solution,
> >it could be generalised to higher levels.
> 
> 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.

In this case, the strings are logically in a tree structure, with two
levels:  1. the port names,  2: the labels. If we would add support
for hierarchical menus instead of simple enumerations, the number of
levels would increase.

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.


> besides, it has been shown that you need not limit yourself to double
> usage of existing descriptor members to maintain binary compatibility.

It's not 'double usage' but generalisation, see above.

> i know you can do better.

Sure.

-- 
FA