[gmpi] Re: Topic 4: Host Interface
- From: Marc Poirier <marc@xxxxxxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 1 Apr 2003 20:44:26 +0200 (CEST)
Yeah, the graph is all audio / music data. But there's more to deal with
than just the components in the graph (host communication, UIs of any
sort, etc.). Hmmm, I'm not sure I'm following you entirely, though...
I'm thinking to myself, "sure, that's the graph, but if that's all we had
we wouldn't be talking about this," but I'm also feeling like I'm not
quite seeing everything that you're getting at maybe...
Marc
On Tue, 1 Apr 2003, Angus F. Hewlett wrote:
> 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
----------------------------------------------------------------------
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:
