[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: thockin@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 29 Nov 2005 13:23:03 -0800
On Tue, Nov 29, 2005 at 12:24:42PM -0800, Chris Grigg wrote:
> >> Maybe, but it's more structured. I like the idea of having a basic event
> >> to
> >> which atributes can be attached.
> >
> >Yeah, there's something simple and less complicated about using this,
> >instead of multiple discrete events. It's a data normalization problem.
> >The more normalized we get, the more intricate it gets, but the more
> >flexible it gets.
>
> . . . m u s t n o t c o m m e n t . . .
> OK. Aside from not getting why we're changing the control system
> design, something about this scheme is just not gelling for me.
We don't have a design, we have a proposal - self-identified, if I
recall, as a straw man. It may be the best, but we're NOT married to it,
yet. Hopefully, this isn't just a spurt of interest, and we can resume
some work on this. Then we can evaluate from a real implementation level
what makes most sense.
> (1) One of the examples had messages addressed to things called v0 &
> v1, but usually you want the plug to do voice allocation. So what's
> up with that?
Virtual voice IDs. The host has an idea of all the voices it has
requested be started. Thos voices map to real voices inside the plugin
according to plugin-defined rules. The host should only operate on
virtual voices.
> (2) If you separate out all the parameters into separate messages,
> how does the plug know when the sender's finished sending parameters?
> If it's just waiting for the 'turn note on' message, then
To keep up this particular example idea: You send all of the parameters
that apply to the start of a voice at the same timestamp as the voice-on.
When you hit the next timestamp, you've got them all and can process that
voice-on.
> (a) is it -really- reasonable to rely on senders to always do the
> 'turn note on' message last?
> (b) Can you -really- rely on the pipes to always preserve message
> transmission order (think TCP/IP etc.)?
Nope. I have somewhere an older email that talks about this - you need to
process all the events for a sample frame before generating audio for that
frame.
> >However you ask the control port for it's metadata will include that info
> >- a flag or a special control port type or something. Think of it as a
> > flag - it keeps it simple.
>
> What does a separate port per parameter achieve that parameter
> addresses within a single port does not?
Well each parameter has it's own metadata, right? That's necessary. We
aren't married to an implementation model yet, so it may be that a plugin
has a single parameter queue and each event contains a parameter address.
Or it may be that each parameter has it's own queue and events do not have
a parameter address. Or it may be something somewhere in between.
Example from XAP design:
During load the host iterates over each parameter. For each
parameter, it asks for the event queue and a cookie. The plugin
decides whether parameters share event queues or not. The plugin
can return the same event queue for all parameters if it wants.
When the host puts an event on a queue, it puts the cookie into
the event. The plugin can use the cookie as a parameter address,
if it is sharing event queues.
Again, this is a normalization problem. This is a much more flexible
design, but may just be overkill.
----------------------------------------------------------------------
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:
