Subject: Re: [linux-audio-dev] more on XAP Virtual Voice ID system
From: David Olofson (david_AT_olofson.net)
Date: Tue Jan 07 2003 - 00:39:14 EET
On Monday 06 January 2003 23.04, Tim Hockin wrote:
> > 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.
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.)
> 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.
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.)
> 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 ---
This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 00:41:22 EET