[gmpi] Re: Parameters / controls / GMPI event system - refreshment

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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: