Subject: Re: [linux-audio-dev] defending simplicity
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Tue Mar 28 2000 - 01:23:03 EEST
the LADSPA is supposed to be THE api for audio plugins, as far as I
see. it's going to be use for different purposes, on different HW,
right?
while you can argue that you can do whatever you see as useful with 32
bit data (or 24 or whatever other number of bits you think is OK) it
does not apply to all situations. in some cases you might want to have
lower quality stream if bandwidth and/or memory is scarce. in some cases
you might want to have 64 bits because of intensive DSP processing that
looses precision quickly... etc... just because typical computer can
process 32 bit audio now (in reasonable time) does not mean that it is
good for each particular use...
this is currently out of scope but: you might want to process other,
non-audio data in the same framework - like midi or other control
data... provide support for data visualisation etc... since all is
stream of bytes I see no reason not to simply allow any data type. I
mean, what's the difference?
question: why is the above (non-audio data) out of scope? when
designing a framework for audio system (a way for audio processing
programs to communicate), the care must be taken that specific audio
requirements are met (bandwidth, enough processing power, real-time
response/processing in some cases etc.). but there is no reason to limit
the system to audio only - after all you have to pass controlling
information, if you are processing audio you might also want to process
midi in the same framework and possibly other data... and since these
have same (or even lower) requirements as audio data, what is the reason
not to allow these data?
erik
David O'Toole wrote:
>
> Erik Steffl wrote:
> >
> > actually, it's a good design philosophy (OK, it's not complete
> > philosophy, it's a part of it). it applies to programming (and life) in
> > general, not only to that particular example.
> >
> > are you arguing with it or just correcting the scope/name of it?
>
> The "don't statically allocate arrays" thing is also called the
> "zero-one-infinity" principle. It means that you should have zero, one,
> or an arbitrary number of things. That is, one is often an acceptable
> magic number, but if you have already written the extra code to do
> several, there is often (not always) no good reason to limit it.
>
> But don't take this as dogma; it's a rule of thumb to be decided in each
> case rather than summarily without real thought. If it will be difficult
> and would serve no useful purpose, then don't bother. Don't argue that
> it is never difficult to make such changes; in the issue at hand, no one
> is just suggesting that the author simply change a #define from 32 to
> 64. Surely larger code/design changes are at stake if we are even
> debating the one/many issue at all.
>
> > I hope you're not suggesting that having arbitrary limits is a good
> > thing...
>
> "Arbitrary limits" is way too vague a phrase to either advocate or
> denigrate. Which kind of limits do you mean? Where? I was referring to
> design, not coding, and I was talking more about *non-numeric* limits.
> Of course I do not think 640K memory is a good idea. But all *designs*
> must have limits, or you will just never stop designing. UNIX is a great
> design, with the fundamental limitation that it won't iron my shirts.
> This is acceptable because doing my laundry is not considered to be
> within the scope of OS design.
>
> My point is, we do not need to automatically assume that some software
> limitation is stupid/evil/insert word here. Usually there is a reason,
> often related to scope and cost/complexity of implementation. Even
> judging by the debate here (which did not change my opinion) it is not
> yet proved whether or not it is neccessary to have many data types, or
> whether it is worth the effort even when it would be useful. No, I do
> not advocate "arbitrary limitations", whatever that means. But if you
> are on the "one format is fine" side of the debate, it does not seem at
> all arbitrary, so there's no philosophical issue.
>
> Examining the issue substantively is more likely to deliver an answer
> than is yet another Battle Of The Methodologies.
>
> --
> @@@ david o'toole
> @@@ dto_AT_gnu.org
> @@@ www.gnu.org/software/octal
This archive was generated by hypermail 2b28 : Tue Mar 28 2000 - 01:47:57 EEST