Subject: Re: [linux-audio-dev] Plug-in API progress?
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: ti syys 21 1999 - 11:36:29 EDT
>From: David Olofson <audiality_AT_swipnet.se>
>
>Back from Malta, and it's friday. :-)
Welcome back! I have updated my GASP pages to have a list of commercial
API resources (see the section "APIs" in the list of commercial softwares;
http://www.funet.fi/~kouhia/gasp/).
I have an idea: the discussion goes to quite deep matters but we could
in the first place make a quite simplified plug-in API. So that, it
doesn't take two years yet again before we have the plug-in API.
We basically need input and output connections. For audio data, they
will be buffers of the given length -- processing is done from input
buffer to output buffer. For control data, they will be either buffers,
event lists, or static data.
Some commercial plug-ins indeed have a GUI for drawing curves and so on.
We could agree type of those curves and curves would be given to the
plug-in (as static data or as event at run-time) instead of plug-in
allowing the user to draw them.
We could assume the plug-ins are included at compile time. So, no GUI
or names are needed. The programmer looks the inputs and outputs from
the plug-in reference book.
This would be easy to do and the plug-in development could go on
immediately. At least Quasimodo needs GPLed opcodes to replace the
original opcodes and this would be a good place to make the opcodes
available for any audio software.
Here is my rough try on this. This looks so simple that you should look
if I just have goofed. This is *not* the final version we have to think
about good structure and field names and their final types.
#define PLUGIN_INOUTTYPE_NONE 0
#define PLUGIN_INOUTTYPE_BUFFER 1
#define PLUGIN_INOUTTYPE_EVENTLIST 2
#define PLUGIN_INOUTTYPE_STATIC 3
struct {
int begintimeoftheplugincall;
int inouttype;
char *buffer;
int numberofsamplesinbuffer;
event **eventlist; /* buffer of pointers to events */
int numberofevents;
void *static;
} inout;
struct {
int time;
what to put here?? int idata, float fdata, char *anydata?
} event;
The effect has a data structure:
f = (filter *)malloc(sizeof(filter));
and default values:
filter_setsamplerate(f,44100);
filter_setfreq(f,400.0);
filter_setboost(f,-20.0);
and if plug-in is general:
filter_setchannels(f,2);
filter_sampletype(f,SAMPLETYPE_FLOAT);
The runtime call would be
filter_do(f,inout *input, inout *output, inout *freq, inout *boost);
where input and output would get buffers and where freq and boost would
get events.
We could agree the static and event curve data is a polyline, and that
the plug-in decides if the curve is actually polyline or spline. So that
it is safe for a plug-in to send polylines to parameter port of the next
plug-in.
By anyway, if this discussion made you think a better simple plug-in API,
will it be only good because we need fast suggestions for this quickly
written simple plug-in API.
I propose that we *end the discussion* on this simple plug-in API
at **October 11**. Then I will write my current set of filters to conform
this simple API and will call plug-in writers.
October 11, that is it!
Yours,
Juhana
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST