Re: [linux-audio-dev] more on XAP Virtual Voice ID system

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] more on XAP Virtual Voice ID system
From: robbins jacob (jacobrobbins__AT_hotmail.com)
Date: Tue Jan 07 2003 - 21:42:31 EET


>>It's obvious when you consider that "VVID has no voice" can happen
>>*before* the synth decides to start the voice; not just after a voice has
>>detached from the VVID as a result of voice stealing. At that point, only
>>the value of the control that triggered "voice on" will be present; all
>>other controls have been lost. Unless the host/sender is somehow forced to
>>resend the values, the synth will have to use default values or something.

>OK... I was thinking that the initial mention of the VVID would cause it
>creation (be that implicit or explict, though I prefer explit I think),
>thereafter control changes would be applied the the instantiated voice (or
>the NULL voice if you've run out / declined it).

The initial mention of the VVID is the issue here; certain types of voice
events are assumed not to allocate a voice (parameter-set events). THis is
because there is no difference between a tweak on a VVID that has had its
voice stolen and a tweak intended to initialize a voice that arrives before
voice-on. We must conclude that the plugin will discard both of them. There
must be a signal to the plugin that a VVID is targeted for activation. we
have a few options:

---a voice-activation event is sent, then any initializing events, then a
voice-on event

---a voice-on event is sent, with any following events on the same timestamp
assumed to be initializers

---a voice-activation event is sent and there is no notion of voice-on, one
or more of the parameters must be changed to produce sound but it is a
mystery to the sequencer which those are. (I don't like this because it make
sequences not portable between different instruments)

---events sent to voiceless VVID's are attached to a temporary voice by the
plugin and which may later use that to initialize an actual voice. This
negates the assumption that voiceless VVID events are discarded.

   #2 is just an abbreviated form of #1, as i argue below. (unless you allow
the activate-to-voice_on cycle to span multiple timestamps which seems
undesireable)

> > > > When are you supposed to do that sort of stuff? VOICE_ON is > > >
>what triggers it in a normal synth, but with this scheme, you > > > have to
>wait for some vaguely defined "all parameters > > > available" point.
We can precisely define initialization parameters to be all the events
sharing the same VVID and timestamp as the VOICE_ON event. This means that
the "all parameters available" point is at the same timestamp as the
VOICE_ON event, but after the last event with that timestamp.

If we want to include a VOICE_ALLOCATE event then the sequence goes:
timestamp-X:voice-allocate, timestamp-X:voice-parameter-set(considered an
initializer if appropriate), timestamp-X:voice-on, timestamp-X+1:more
voice-parameter-sets (same as any other parameter-set)

But this sequence can be shortened by assuming that the voice-on event at
the last position for timestamp-X is implicit:
timestamp-X:voice-on(signifying the same thing as voice-allocate above)
timestamp-X:voice-parameter-set(considered an initializer if appropriate),
(synth actually activates voice here), timestamp-X+1:other-events

---Jacob Robbins.................

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 21:50:57 EET