Subject: Re: [linux-audio-dev] plugin ideas based on Guenter's mix plugin API
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: ma elo 30 1999 - 16:40:23 EDT
On Sun, 29 Aug 1999, Guenter Geiger wrote:
> Can you tell us more about the design of ecasound plugins ?
> I guess ecasound uses plugins for a longer time. Can you post
> the header of the plugin base class ?
Well I should first clear some issues. First of all, currently
ecasound is not a very efficient program. Before switching to
C++, ecasound was written in C and in a traditional
performance-centered style. After switching to C++ (and a lot
of coding in Eiffel :)) I noticed that concentrating on clean
and simple design makes so many things easier. And what's extremely
important for me, this makes it fast&easy to continue with
a project after a longer break. But I understand that most
areas of audio programming require the performance that you get
by optimizing your code. So ecasound effect API won't suit this
open plugin project...
However, I think that some design aspects of ecasound's effect-API
might be good to keep in mind. First, writing a new effect for ecasound
is really simple... Here's a few header lines...:
--cut--
class CHAIN_OPERATOR {
[...]
virtual void set_parameter(int param, double value);
virtual double get_parameter(int param);
virtual string status(void);
virtual int number_of_params(void) const;
virtual string label(void) = 0;
virtual string id_string(void) { return(""); }
virtual void process(SAMPLE_BUFFER* sbuf);
virtual void process(SAMPLE_BUFFER::sample_type *);
--cut--
Implementing [sg]et_parameter enables realtime control.
Status() is meant for simple non-continuous messages.
Number_of_params() is, well, self-explanatory. Label()
is a informative name for the effect while id_string()
is a ecasound-specific name (used in the user interface). And what's
left is to implement one version of process()... First one takes a
whole buffer while the other takes a pointer to a single sample.
SAMPLE_BUFFER class offers all the info needed about the sample
parameters and a a bunch of useful routines for handling sample data.
So you don't really need to do much. There are some other
functions you might want to implement (effect name, etc), but
they are all trivial to implement. Now the effect is ready
for MIDI/oscillator control and it can be combined with other
effects in serial and in parallel.
This approach is too simple for a general plugin-API, but
I still like the interface very much. This is why I hope that
OPA/whatever's API doesn't get too complex.
-- Kai Vehmanen ----------------------------- CS, University of Turku, Finland : email mailto:kaiv_AT_wakkanet.fi : audio processing for linux http://www.wakkanet.fi/ecasound/ : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST