Subject: Re: [linux-audio-dev] Plug-in API progress?
From: Benjamin GOLINVAUX (golinvaux_AT_benjamin.net)
Date: ti syys 21 1999 - 13:16:36 EDT
----- Original Message -----
From: Juhana Sadeharju <kouhia_AT_nic.funet.fi>
To: <linux-audio-dev_AT_ginette.musique.umontreal.ca>
Sent: Tuesday, September 21, 1999 5:36 PM
Subject: Re: [linux-audio-dev] Plug-in API progress?
> >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