[gmpi] Re: R: Re: Topic 4: Host Interface
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 31 Mar 2003 17:12:51 -0800 (PST)
> occur simultaneously, and the plugin returns an event. The plugin does
> not execute this event. This allows the plugin to implement linked
> controls, control quantization, and anything else it wants. Because the
> control changes does not occur here, the host can create events on any
So the host has to call this method for every frame for which there exists
an event? And the host then needs to interpret and propogate the returned
list of events and propogate that back to all controllers. ick.
If we want to explore that route, how about a 1-call per event target per
timeslice method.
Pass all the events to a plugin->control_events() method. This method can
validate events (or not - this may not be a good idea to allow control
changes to fail), recognize linked controls and generate events for them,
and enchain the passed events. The method can return a list of events that
need to be passed back to controllers - errors or linked-knob changes. The
simplest plugins can do nothing at all for this hook. This also allow for
spontaneous changes of controls.
It really splits the processing of events into pre-processing and
processing. Which may have bad effects and good effects on performance.
Take some stuff out of the DSP path, but duplicate some effort. It should
be safe, too, as I think we can assume that once we reach the boundary
before the next time slice, we know everything that is to happen in that
timeslice.
This is still not very pretty. A plugin may have many event targets - one
for each knob, even. It adds a lot of function calls per-timeslice, which
is exactly where you DON'T want overhead.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
