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