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

[Fons Adriaensen]

On Tue, Mar 09, 2004 at 06:49:46PM +0100, Tim Goetze wrote:

> 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. :)

It's not impossible to get them, and in fact I'm using five versions
(for different targets) of g++ daily. It's just that I'm not paid to
do this during work hours, so I limited the code to the essential part.
In fact Alcatel Space paid for all the replies to your posts today.

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

But still trivially simple. If someone writing a host falls over this,
he will probably never reach the end. There are much more complicated
issues to deal with.

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

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

"For historical reasons". It's in the good company of the 'gecos'
field in /etc/passwd for example. 

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

I never claimed compactness or versatility as a virtue. It *is* readable
and simple. Nothing in C is ever foolproof - an invalid pointer will 
hit you no matter how you implement the enums. There's the demolition
tool to test for this. 

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

As I said, it's a different problem. And your proposal is a clean way
to solve part of it. But IMHO it should be generalised, but then it
probably enters the RDF domain.

-- 
Fons