Yeah, now you're reminding me that I addressed this issue recently, too, with the internal plugin "meta API" that we (Destroy FX) use. :) The process-events-immediately-before-time-slice-render approach does have an undeniable appeal for the DSP component, but not other things. Because of this, our internal DSP component system does wait until immediately before rendering a time slice to "react" to the latest parameter values. That works well for us for the audio aspect. But anyway, I think the issue really is that the audio component is the only thing that really needs any precision with events. So that's why we care about locks, synchronicity, immediacy, timing, etc. while anything else can easily make due with asynchronous notifications. So maybe what we really want is the best of both worlds: two event queues. One is for the DSP component and addressed immediately before rendering a time slice, and the other is available to other listeners and emptied at whatever idle/update rate those listeners access the data. Ugh, I'm sorry, I'm a little not-so-clearheaded this morning, I hope this stuff is coming out in a readable fashion... :-/ Marc On Tue, 1 Apr 2003, Laurent de Soras [Ohm Force] wrote: > > Marc Poirier wrote: > > > > Then the event > > doesn't really get passed (and therefore listeners like GUI elements don't > > get updated) until rendering begins again. This can cause unwanted > > unresponsiveness for some types of events. At least that's how it seems > > to me, but I might be missing something with this approach... > > Absolutely, I had the same problem while designing PTAF some > times ago. I chose to add an interface to send asynchronious > parameter changes but I'm not happy with it. However I have > several ideas for workarounds, keeping only one way to change > a given parameter, I will develop them later. > > -- Laurent > > ==================================+======================== > Laurent de Soras | Ohm Force > DSP developer & Software designer | Digital Audio Software > mailto:laurent@xxxxxxxxxxxx | http://www.ohmforce.com > ==================================+======================== ---------------------------------------------------------------------- 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