Subject: Re: [linux-audio-dev] Plug-in API progress?
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: ke syys 22 1999 - 11:30:15 EDT
>From: David Olofson <audiality_AT_swipnet.se>
>
>Conditional code is complex and expensive. I think the low level data flow
>should consist of only two data types: raw data and events. What actual data
>formats we're really dealing with will be hardcoded in the plug-ins anyway
I were thinking that some might want keep the gain (say) constant,
changing time to time, changing constantly. If the plug-in fixes the
type, then should we have N+1 different version of the same plug-in?
Or how?
>Static data? Isn't a single out-of-band event enough, or are we thinking
>about different things?
Anything the particular instantiation of the plug-in might use.
>> #define PLUGIN_INOUTTYPE_NONE 0
>
>For padding or what...?
The plug-in will use the default value if the gain parameters has no input.
I think NULL as a function call argument does the same.
>> #define PLUGIN_INOUTTYPE_BUFFER 1
>> #define PLUGIN_INOUTTYPE_EVENTLIST 2
>
>Another way to handle Event Ports (as I call them for now) is like something
>you create during the instantiation of a plug-in (create any number you need).
>Don't know if there's really much point in having multiple event inputs on a
>single plug-in...
If a plug-in has both the frequency and boost parameter in the function
call, you need two eventlists (if events are used on those parameters).
The event actually means "change the gain to value <event value>".
There is no any target info on the events so that the events such as
"gain please! change yourself to <event value>" cannot be sent (to that
unique port).
If we later add such a target system, then the targets can be parsed
at building time and be hardcoded the above way at run-time.
>Do you put multiple channels in the same buffer here?
Good question. I planned to provide the number of channels, samplerates,
etc. as one static input. It is the matter of building time and not
of run-time.
The samples are interleaved in the buffer. Event should also have
simultaneous data for all channels if the parameter affect to all
channels.
>How about
> int time;
> int code; /* What is this? */
Leave this out because it is hardcoded at network building time.
We know it already.
> int from; /* Who is this from? */
Hardcoded. Or no need to know.
> int size; /* Number of data bytes */
> /* dynamic size data follows... */
Hardcoded. Basically the time and arbitrary data (which the plug-in knows
how to cast) are needed.
>so we might be able to have dynamic event size from the start.
Yep.
>> f = (filter *)malloc(sizeof(filter));
>> and default values:
>> filter_setsamplerate(f,44100);
>
>One of my latest wild ideas it to replace this entirely with the
>event system.
Above calls are not called by the engine but the network builder.
>No struct, just a callback function that the engine asks about properties
>when instantiating a plug-in, or just wants some general info anout the
>plug-in class.
I would layer the data this way:
-the things needed when the plug-in flows the audio;
-the things needed to add the plug-in to the network.
The simple API I were thinking would let the second part to the
programmer of the application. He would know early all the plug-ins.
Because we are including only the audio flow data structures to simple
API, the more complex system can be build over the simple API.
I think even the random access wave editor plug-ins would use the flow API
for the actual processing when and if possible.
>> 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.
>
>I think
> filter_do(f, void **inputs, void **outputs, event **events);
>will do.
No if we hardcode the event paths.
>Also, no output buffer for events.
They are in my system.
>Yeah, but there's a slight timing problem here; how do you know where you're
>headed before you've recieved the next point?
If you need to know the curve very well, it can be edited in the editor
and given to plug-in as static data. If sent as events or buffers, we
face the same latency problems as with audio or MIDI data.
>Well, even if my event system might be more complex than what you had
>in mind
I would like to go the simple hardcoded way and only later look at the
general event system.
I think we will use the closures as used in Csound and in Quasimodo. They
are quite the same what I proposed but less parameters at function calls.
Paul, I now notice that I use the f in function call
filter_do(f,inout *input, inout *output, inout *freq, inout *boost);
to carry sample rates, default values and all such infos. I guess forgot
it myself and described something else to you in my private mail.
Yours,
Juhana
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST