Subject: Re: [linux-audio-dev] defending simplicity
From: Tommi Ilmonen (tilmonen_AT_cc.hut.fi)
Date: Tue Mar 28 2000 - 11:29:32 EEST
Actually a mail in two parts.
PART 1:
Kai has good points.
On Mon, 27 Mar 2000, Kai Vehmanen wrote:
> Here's a few random thoughts about simplicity:
>
> 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
> API generic. Everything is just a stream of bytes, that shouldn't
> be a suprise to anyone. Why don't we just define a generic
> API for transmitting the bytes and a single format string. I
> want to write a Tetris for LADSPA.
And why not think about a generic media API. Sound, MIDI, image,
structured models - all under one nice plugin API. Nice - or may be not.
Even better: plugin for everything.
> Most open-source developers just aren't interested in these large
> APIs. It takes time to understand how they work, and even more
This applies to all developers I believe, be they open-source or not.
> time to see whether they are good enough for task you want to do.
This is somewhat related:
I am in the process of restructuring Mustajuuri. I will separate all
the low-level DSP stuff (basic filters and delays) to one
library. That library is in turn small and independent of any other
library (STL, Qt, libxyz). I am doing this partially to make Mustajuuri
code tree cleaner, but also to make make part of it potentially more
accessible to people.
These are fundamental tools like linear and median filters that are
relatively optimized. Just a small C++ library with a few classes and a
few methods. In many cases a library is easier to use than some plugin API
(and sometimes vica versa).
Right now the APIs are rather incoherent and not so logical ...
there are random issues that need to be solved. I am not out to
build an all-purpose signal processing library, but a library with a few
practical utilities, decent performance, simple interfaces and no
unnecessary dependencies. In particular it does not contain any way to
connect the objects (which tends to be the fundamental difference between
many projects and cause for n^m arguments).
I wonder if other people would find such lib useful ?
Anyways, it will eventually appear.
> And if LADSPA doesn't become popular, why use it? Another fact
> is that nearly all audio apps written in C have their own
> plugin APIs.
PART 2:
I might add one random tought of my own.
I have been in (failed) projects to create a common audio plugin API.
The script:
Coders start to discuss code with some very hazy idea of the final app.
Then people argue about how the code should be written. Most disagreement
is in fact caused by different idea of the final app(s). In the end people
will realize that the apps they had in mind are completely different and
require different approach (down to the lowest levels). All
plugins do depend on the application. There is always some limit to how
generic a plugin can be. Some people will tell that minimal API is GOOD.
Some say that a flexible (=big) API is GOOD. Both sides have solid
arguments to back their opinions. Flame-war. The lowest common denominator
becames so small that it is useless. Besides, the discussion has already
turned sour and there is little left to rescue.
After this sort of experience I decided to write the whole thing myself -
it is easier and faster. I can do whatever I want and people will not
bother me (nor I them). I have no need to compromise anything to make
things more accessible for all possible purposes.
Things do not have go like this. With LADSPA there are people who
actually know what are the problems and issues that are necessary (this
isn't always the case).
Tommi.
This archive was generated by hypermail 2b28 : Tue Mar 28 2000 - 12:03:25 EEST