Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
From: Fons Adriaensen (fons.adriaensen_AT_skynet.be)
Date: Tue Mar 09 2004 - 21:29:50 EET
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
This archive was generated by hypermail 2b28 : Tue Mar 09 2004 - 21:35:51 EET