6 Jan
2003
6 Jan
'03
6:45 p.m.
On Monday 06 January 2003 23.04, Tim Hockin wrote:
Problem is that that requires special case event processing in
synths. You'll need an inner event decoding loop just to get the
parameters, before you can go on with voice intantiation.
The alternative indeed means that you have to find somewhere to store
the parameters until the "VOICE_ON" arrives - but that doesn't screw
up the API, and in fact, it's not an issue at all until you get into
voice stealing. (If you just grab a voice when you get a "new" VVID,
parameters will work like any controls - no extra work or special
cases.)
It's not really "space", but rather a minimalistic approach to
senders allocating "handles", and receivers marking them, to avoid
searching.
When you get a new VVID, you just look the corresponding entry up in
the global array and point it at the physical voice you allocated.
When you get further references to that VVID, you can just look at
the entry and there's your voice; no searching.
(This obviously assumes that senders set new VVIDs to NULL, so synths
can tell them from VVIDs with assigned voices.)
The main
difficulty I see with the VVID system is how to
initialize parameters on a new voice before the voice is
activated with a VoiceOn event.
After, or rather - at the same time. The host just has to make
sure the VoiceOn arrives first. This is what is currently in the
header in my working dir. Send a new VVID to the VOICE control with timestamp X
for note-on
Send any initial voice-params with timestamp X
Send 0-VVID to the VOICE contol with timestamp Y for note-off
I'm not quite following with the 0-VVID thing here... (The VVID *is*
the common reference; that was the idea.) You can't know when a synth
is *really* done with a Voice without a round-trip - but indeed, you
can tell the synth that you have nothing further to say to this Voice
by implying that NOTE_OFF means "I will no longer use this VVID to
address whatever voice it's connected to now." Is that the idea?
If so, I would suggest that a special "DETACH_VVID" control/event is
used for this. There's no distinct relation between a note being "on"
and whether or not Voice Controls can be used. At least with MIDI
synths, it's really rather common that you want Channel controls to
affect *all* voices, even after NoteOff, and I see no reason why our
Channel Controls should be different.
Alternatively, rather than a VOICE control, just have
special
VOICE_ON/VOICE_OFF events.
That doesn't really change anything. Whether you're using
VOICE_ON/VOICE_OFF or VOICE(1)/VOICE(0), the resulting actions and
timing are identical.
-first- order
on timestamps
-second- put voice-on ahead of all other event types.
A little ungainly, but effective as it frees the plugins to
assume that they'll get voice-on first but must consider all
other events on that timestamp as arguments to the initialization
of the voice. Of course this
not all events with that timestamp - only per-voice controls with
the VVID that was just turned on. All per-voice events have a
VVID. So it is easy to know if that VVID is active - if not, the
host screwed up.
What I am still fighting with is the idea that the host
pre-allocates VVID space. How much space for each VVID?
4 bytes. (On 32 bit archs, that is.)
Any
imposed structure?
Nope, just a void * that the synth may use in any way it likes. (Or
ignore, if it's using some "tag + search" approach; you need only the
VVID [index] for that.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---