Re: [linux-audio-dev] defending simplicity

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] defending simplicity
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Wed Mar 29 2000 - 00:51:18 EEST


Forwarding this back to the list... Erik, I hope this is ok.

On Mon, 27 Mar 2000, Erik Steffl wrote:

>> beyond the simple case brings more possibilities. I've repeated this many
>> times, but it's much easier to build complex setups from simple
>> components than to split complex setups into pieces and rebuild.
> yes, that's generally true. but LADSPA is a framework - you want it to
> be flexible enough not to have to create new version everytime you find
> out you need new data format etc...

Actually it isn't. It's a standard interface for a set of audio
related function callbacks. No IPC, just a plugin API.

> the lowest common denominator: I think that a good goal but I think
> that you interpret it that it should do only absolute minimum of what
> people might want. I think that the interpretation of what the minimum

No, it's the l-c-d of ways to implement effects.

> we need is more along the lines: system that can be used by everybody
> (=simple core), but does not limit anybody (=extra things are there to
> use but not forced). just like C++ :-)

Well, I use C++ all the time, but I don't think it's that great. Compared
to Eiffel (my current favorite), C++ is a big mess - combination of new
ideas, backwards compatibility and something-for-everyone extensions. And
that's just what LADSPA is heading to.

> regarding recompilig: are you suggesting recompiling the whole
> application (host) + all plugins? more important - if you need some
> particular non-standard data-type (i.e. not 32 bit float or soemthing
> like that), you probably need it for some specific reason - that does
> not mean that the whole application need the same data format. I guess

So you'll use your new type inside the plugin. If you are dealing with
audio, you can always convert your data to float numbers. And yes, I'm
suggesting to recompile everything. Converting a buffer of doubles to
floats is *expensive*. You don't want to do that inside your flow system.

> you would want to use more then one data format simultaneously. or on
> the fly - for example you might want to do some real time processing
> using lower fidelity and do the real processing in batch mode... or
> something like that...

Then you should consider not using LADSPA. That's just what people are
doing now. And if we don't have a good standard (hosts compatible with all
plugins), this will continue to be the situation. If we come up with
"the perfect plugin API" (tm), but nobody uses it, well, what's the point.

I have been taking part in this discussion since it began in Jul
1999. Everytime we are close to a solution, someone comes with a new set
of features. In the end, it is code that counts. So far only David, Benno
and Richard (sorry if I forgot someone) have written actual code. I'm a
lousy C-coder myself, so I just concentrate on complaining. :) ... but if
you have better ideas and examples, show me the code and I'll shut up.

-- 
Kai Vehmanen <k_AT_eca.cx> ---------------- CS, University of Turku .
 . audio software for linux ...	http://www.eca.cx 		 .
 . armchair-tunes mp3/wav/ra .. http://www.wakkanet.fi/sculpcave .


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Mar 29 2000 - 02:21:01 EEST