Subject: Re: [linux-audio-dev] defending simplicity
From: David Olofson (david_AT_gardena.net)
Date: Thu Mar 30 2000 - 08:09:13 EEST
On Mon, 27 Mar 2000, Juhana Sadeharju wrote:
> >From: Kai Vehmanen <k_AT_eca.cx>
> >
> >1. It's not about genericity, it's about focus.
> >
> >Anyone remember the old Unix guide-line - "make your program do
> >one thing well"? Of course we could go on forever making the
>
> There are also some suggestions to not make unnecessary limits to programs.
> See GNU coding style.
I agree. I have been forced many times to rewrite code that was based
on a too focused/specialized design. I also have quite a few
experiences of a little extra flexibility saving lots of time later
on, when the unexpected, "unrealistic" features are needed yesterday,
with no time for experimenting.
Also, there is a big difference between flexible designs and creeping
featurism. The former is what you get if you support what makes sense
without adding lots of stuff. It's basically about making APIs
reusable in all sensible ways. The latter is what you get if you're
too fond of the start-simple-and-extend philosophy.
It's all about balance between simplicity and flexibility. In most
cases, it has to be designed in, as it can't be added afterwards.
> >want to write a Tetris for LADSPA.
>
> What kind of system makes it possible?
Well, just about any system, as long as the game plugin can
communicate with a custom UI. Not that it makes much sense... :-)
> You define a new type 123. Your plug-ins knows that type and can
> discuss together. You may help the engine by telling how much bytes
> your type is.
>
> Now are those additions too complex?
>
> If my application doesn't know what those 123 types are, it just cannot
> use those plug-ins or connect them.
>
> This kind of scheme is in use in AIFF file format. It would work perfectly
> for us too.
Yes... Very nice file format indeed. The Amiga used it for almost
everything, allowing things like bundling different kinds of data
in a single file, while still allowing programs to transparently
extract the data they understand. No extra code. It's just 4 byte
chunk IDs and a chunk size fields - decode the chunks you understand,
and ignore the rest.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Thu Mar 30 2000 - 13:27:14 EEST