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

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 1 Dec 2005 09:19:20 +0100

On Thursday 01 December 2005 05.43, thockin@xxxxxxxxxx wrote:
> I guess you can do almost the same without explicit allocation.  If
> you get events for a VVID you don't currently care about and there
> is no note-on message on the same timestamp, then you discard all
> the events for that VVID.

What I don't like about this particular part is that it complicates 
the implementation. When decoding and handling events, how do you 
know that there is no note-on on the same timestamp, unless you 
always decode in two passes?

I used to think of timestamped events as an efficient way of doing 
away with the "control rate" restriction without going all the way 
and using audio rate streams for all controls. I suspect that 
protocols that require multi-pass event decoding and similar by 
design, may quickly eliminate this property and/or add a lot of 
complexity to implementations.

Anyway, if events are guaranteed to arrive in order (that is, not just 
timestamp order), and the rule is "don't talk about what you have not 
allocated", I think things become simpler. Besides, if a sender is 
going to send a note-on/allocate or similar event for a particular 
timestamp, it already knows that it's about to ask for a new voice, 
and may as well say that first thing, right...?

In a traditional (physical) voice stealing scheme, the synth would 
decide when to detach a VVID from it's physical voice (ie "voice 
stolen"), and then it would simply not care about that VVID from then 
on. Subsequent events for that VVID get trapped in the "unknown VVID 
- discard event" case, which, I believe, will be needed anyway for 
robustness and simplicity. (Without it, you'll get in serious trouble 
if you make a "hot" connection at the wrong time, potentially 
crashing a synth with events regarding a voice that was "allocated" 
before the connection was made.)

The only way to bring a dead VVID back to life is exactly the same as 
introducing a brand new VVID; you need to tell the synth you want to 
allocate a new VVID.

Now, if you want to implement a more advanced voice stealing scheme, 
where "dead" voices can be brought back to life when higher priority 
voices are stopped explicitly, this can still be done. You just need 
to separate voice control state from voice implementation state, so 
you can detach a physical voice from it's control state, without 
detaching the VVID from the control state. Then, when stealing a 
voice, you just leave the control state object around, VVID attached, 
until you decide to steal that too, you give it a new physical voice, 
or the sender says it won't be using the VVID any more.

> In truth, this more minimal model may be missing some of the
> requirements, I haven't worked it all out fully, but I *think* it's
> all covered.

I don't know if it clearly fails to meet the requirements, but I have 
a bad feeling about attaching implicit allocation semantics to some 
"arbitrary" control...

Then again, it probably simplifies things a bit, and it does reduce 
event density for synths that are designed around "retro" MIDI style 
logic. It still allows synths that are not strictly note oriented 
(virtual theremins spring to mind...) to treat this "note" control as 
a pure VVID allocation/deallocation interface, relying only on other 
controls for physical voice 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: