[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 1 Dec 2005 00:53:03 +0100
On Wednesday 30 November 2005 23.54, Koen Tanghe wrote:
[...]
> 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 also seem to recall I added the
> possibility for the host to specify the voice ID directly that
> should be used for the new voice (instead of letting
> the plugin choose one), but I don't really recall why I added
> that...
> The plugin can assign its voices as it sees fit, but should let the
> host know the ID of the voice for later reference.
The problem with this is that it requires a full
sender->receiver->sender roundtrip after a sender decides to start a
new voice until it can start talking about it. This may not be an
issue when running plugins in a single thread, allowing them to call
into each other back and forth, but it becomes one major PITA to send
something like this over (relatively speaking) high latency
connections, or one-way connections.
This the main reason for using virtual voice IDs instead. They can
basically be tags that the senders invent themselves, or they can be
picked from a host managed pool or whatever - doesn't matter as long
as senders don't have to wait for receivers to return voice IDs.
Senders then stamp these IDs on subsequent events in order to tell
the receiver what they're talking about.
Pretty much like the addressing function of MIDI note numbers, except
they're not tied to pitch, so senders can just allocate numbers as
needed to control the required number of independent voices.
> 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 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?
Roundtrip problem again...
IIRC, in the XAP discussions, we concluded that VVID allocation and
voice on/off control has to be separate to handle this in a clean
way. That is, allocating a voice ID just means "I'm going to fire up
and control something independently here, so I need a private context
for that."
The only reasons why you even tell the receiver about this (since the
actual allocation is done by the sender, possibly with some help from
the host) is
1) that this allows the receiver to prepare a new
context upon getting the "new VVID" event, so it
doesn't have to check for this when receiving
every single control event, and
2) that it allows you to instantly reuse a VVID that
you no longer need by having the receiver detach
whatever is attached to the VVID and then create
a new context for it. (Note that detaching the
VVID should not do anything to any physical voice
that it may be wired to! The action just means
"I'm not going to talk about this voice any more,
so you can forget my ID for it. If I use that ID
again, I'll be talking about a new voice.")
Separating voice allocation/addressing and voice on/off also has the
bonus of allowing instruments to be both monophonic and polyphonic at
the same time. Just use the same VVID all the time for "monophonic
mode".
Use one VVID per string on guitars, violins etc, perhaps...?
[...]
> > 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.
>
> That's more or less similar to what is done in VST now when you're
> using MIDI events to get sample-accurate parameter changes, right?
Sort of, but the simple, naive implementation implementation of what
we're talking about here just requires that you finish processing
events for the current sample frame before doing the audio
processing, running voice state machines and whatnot. Something like
this:
do
{
while(events_for_this_frame())
process_event();
update_event_controlled_state();
for(samples_until_next_event())
process_audio();
} while(more_samples_for_current_buffer())
I don't like the update_event_controlled_state() thing, though. It
basically means you have to check everything in two stages, where the
latter does not scale very well with event density. You end up doing
stuff like setting some "this_voice_needs_updating" flag whenever
receiving an event for a voice, and then you need to check and act
upon all these flags one way or another. Messy and/or inefficient
code.
If events are guaranteed to be received in the order they were sent,
you can do everything in the event handling code while you're at it,
eliminating per-control overhead when there are no events. You can of
course still detach heavy calculations and other stuff you don't want
"hard sync'ed" to the events, but now you are no longer forced to do
that with every single control.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
