Subject: Re: [linux-audio-dev] API design again
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: la loka 09 1999 - 10:46:45 EDT
>> Clearly, a plugin must still be able to handle state changes. But the
>> code to do that will, in most cases, simple be resetting variables,
>> setting flags, etc. This is quite distinct from the task done by
>> process(). If an event generates or actually contains data to be
>> processed, then it goes into the plugin via process(). If it merely
>> tells us about a state change ("MIDI NoteOn", "GUI says value shifted
>> to 0.92", etc.), then the plugin gets told via (we'll call it ...)
>> notify().
>
>...but how would that be done if events are to be processed by another
>callback? It's all or nothing here; no point in moving *some* events out of
>process().
a plugin will almost never be just a function call. it will have some
state that goes with it. the other callback "process_events()"
understands how to parse the events and manipulate the state data.
one thing i prefer about this approach is that it enforces cleaner
conceptual thinking on the part of a plugin designer. the process()
call is responsible for generating data on the basis of the current
state and the amount of data called for; the process_events() call is
responsible for mapping from the event types floating around in the
system to the internal state of the plugin.
this seems like a big win to me.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST