Subject: Re: [linux-audio-dev] API design again
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke loka 06 1999 - 22:02:21 EDT
>Yes but the event is supposed to affect the current executing plugin
>only (my interpretation) and can then be coded as:
> selfHandleEvent(event); // could be inlined by the compiler,
>// or at least it is a static call, no miss in jump prediction.
> engineGetNextEvent(this, event); // Have not seen this
I don't think this is correct. If the event is, say, a MIDI continuous
controller value change, then many plugins may need to know about it
(i.e. all plugin's that want to use the CC value for something).
>shouldn't we be able to process more than one event during one
>buffer....
>(or was the event a linked list)
we'd better be able to ... otherwise, its a stupid design. so yes, i
think you can assume that the `event' is some kind of linked list/null
terminated array etc.
>It also does simplify coding for FFT since you get the same size all
>the time, you would probably need less memory to keep state from
>previous. (Especially if the plugin can specify buffer size)
This is a very valid concern. I was trying to find an example of where
the varying frame count would cause problems - this is a good
one. Anyone else have comments on FFT (or other algorithms) and the
problems that variable frame counts might cause ?
>It should be easy to write a compatibility plugin that calls plugins
>without event handling. The reverse is not true...
>
>// Pseudocode...
>compatibilityPlugin(..., event)
>current = 0;
>for(full range)
>{
> partSize = nextEvent - current;
>
> plugin->process(..., current, partSize);
>
> plugin->processEvent(event);
> current = nextEvent;
> engineGetNextEvent(plugin, event) // the last event is not removed
>}
Excellent example. The question remains: should this be the
responsibility of the plugin or the engine ? Do you really want
*every* plugin derived from non-event-based code to contain this kind
of wrapper ? Doesn't it remove most of the benefits of the approach ?
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST