[gmpi] Re: R: Re: Topic 4: Host Interface

  • From: Marc Poirier <marc@xxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 1 Apr 2003 20:19:04 +0200 (CEST)

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

Other related posts: