[gmpi] Re: R: Re: Topic 4: Host Interface
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 1 Apr 2003 13:22:19 -0500 (EST)
Yes, but isn't our graph really just one big audio component, in a
certain sense? Especially considering that generators/transformers within
the graph may be producing time-sensitive event data of their own?
(thinking arpeggiators, parameter-LFO objects, plugins which
parameter-morph over time in response to incoming changes...)
Regards,
Angus.
On Tue, 1 Apr 2003, Marc Poirier wrote:
> 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
>
>
----------------------------------------------------------------------
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:
