[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:
