[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: thockin@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 30 Nov 2005 15:40:16 -0800
On Wed, Nov 30, 2005 at 11:54:52PM +0100, Koen Tanghe wrote:
> > 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.
>
> In some (very primitive) system I once made, when you started a new "note"
> (I actually prefer "musical object" but anyway...) you can send the "start
> new note" event to the plugin that must start a new voice for it, and the
> plugin returns a voice ID, that the host can store for later referencing. I
The problem with "returning" a voice ID is that it implies syncronous
creation of a voice. I want to start a new note 93 samples into the
current timeslice. Then I want to send a voice-specific event to that new
voice at 118 samples into this buffer. All events for this buffer have to
be delivered before the buffer is processed.
I either have to buffer-split so that the (voice-create,voice-id-return)
cycle happens between buffers, or I have to allocate a voice ID before the
plugin even knows there is a voice.
That second option is a virtual voice ID. The host uses a VVID to tell
the plugin about voices. The plugin uses it to look up real voice info.
The host should not know how many or which voices are really active on a
plugin.
> The plugin can assign its voices as it sees fit, but should let the host
> know the ID of the voice for later reference.
You don't really need to know the actual voice ID, the VVID is enough.
> There's just one thing I remember not being sure about how to handle it: a
> note off message does not kill the voice right away, and the corresponding
> voice ID will be alive for the rest of the release part of that note, during
> which you may stil want to bend its pitch etc... The time when the note
Yes. This is an interesting point. We (XAP folk) had previously
described it like this:
The host tells the plugin that VVID(v) is being allocated. VVID(v) is
now in state VVID_IDLE.
-> The host can send events to VVID(v) in preparation to turn that
voice on.
The host activates VVID(v). VVID(v) is now in state VVID_ACTIVE.
-> The host can send events to VVID(v) to modify it's continuous
per-voice controls.
The host stops VVID(v). VVID(v) is now in state VVID_RELEASE.
-> The host can send events to VVID(v) to modify it's continuous
per-voice controls.
The plugin is eventually done with VVID(v). The plugin notifies the host
that VVID(v) is now in state VVID_DONE.
-> The host can no longer send events to VVID(v).
The host tells the plugin that VVID(v) is being deallocated.
(In reality the first and last steps - alloc/dealloc are not *really*
needed. The allocation step provides a clear semantic point at which a
VVID comes into being. The deallocation is probably just fluff).
There's at least one alternate state series. What if the voice is very
short? Think of a sample player playing a hihat sample. The real voice
is done potentially long before the host asks it to be done. This case is
open for debate. Maybe the plugin tells the host that VVID(v) is in
the VVID_DONE state, or maybe the plugin just has to discard events for
the defunct VVID. Maybe that's a new state.
This deserves a state diagram in the spec :)
> really stopped is determined by the plugin itself, and in order to let the
> host know that the voice has eventually completely died, there should be a
> mechanism that allows the plugin to tell the host that the corresponding
> voice ID has become free again.
> Does this sound reasonable?
Exactly as I've been thinking of it.
----------------------------------------------------------------------
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:
