[gmpi] Re: lost-n-found #3 parameter stuff
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 6 Nov 2004 11:18:49 -0800
On Sat, Nov 06, 2004 at 07:44:29AM -0500, Paul Davis wrote:
> my understanding of events is that they are processed synchronously
> with audio processing. that doesn't work for a GUI that wants to show
> the user a rolling "flow" through a value range. or at the very least,
> it doesn't work very well at all.
Right. every GUI param change has a latency to when it is actually
audible.
> i think that you can't to do this with events, it has to be done with
> explicit, synchronous callbacks into the plugin. also, i think this is
> a massively better design than even the AU model - trying to enumerate
> all the possibilities for parameters is a battle nobody can win.
You think which is a better design?
The design I suggested for increment takes this into account, by
explicitly making the caller send an event. Thus, if the GUI wants to
send an event for every increment, it can. If it wants to have a
rate limit and only send one event per second, it can.
Adding a synchronous way of changing a parameter becomes a locking
nightmare for every plugin devel.
----------------------------------------------------------------------
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:
