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

[David Olofson]

On Wednesday 08 January 2003 10.01, Tim Hockin wrote:
[...]
> All this is ok in concept.  I still think it is too implicit and it
> feels 'sneaky'. I'd MUCH rather see a rigid, well-defined protocol
> that forces the few bizarre instruments to do a bit more work
> (really, just a BIT) than a loose, implicit one that is going to be
> easy to screw up.

What's implicit about it, and how can you screw it up?

If a MIDI synth gets Poly Pressur or NoteOn/Off events, it has to 
handle them properly. The MIDI pitch is the "VVID".

This is exactly the same thing, only a VVID does not imply a note 
pitch value.

As to VVID management, that's a separate issue, and I'm just looking 
for the cleanest and simplest approach. I still think VVIDs with a 
host global table of VVID entries is the simplest way that can 
actually work, but there are other ways - maybe even simler ways.


> VOICE_ALLOCATE: declare a VID as in-use

Ok, this eliminates the need for ever checking VVID entries in a 
synth. Good.

(Although the name is probably not right. You don't really care 
whether you get a physical voice or not, and it doesn't matter to the 
sender. It can confuse things, though - see below.)


> VOICE_CONTROL_SET: set values for a per-voice control for a VID

Yes - and this is where your average synth will have to allocate a 
voice (or a fake "control tracer" voice) - unless it's done in 
VOICE_ALLOCATE.

Anyway, it's optional for synths. My only argument against 
VOICE_ALLOCATE is that it is redundant. Sending any other event to a 
Voice could have the same effect, and would also bring more 
information. (The only information VOICE_ALLOCATE brings is "the 
sender is about to use this voice ID at some point".)


> VOICE_ON: declare that a VID is ready for play

I still don't really see the point with this one. Synths will have to 
allocate a voice as soon as the first voice control event arrives 
anyway, so all this says is "start a note!" - and that doesn't even 
apply to continous velocity instruments.

Sure, I can see where VOICE_ON can be a handy feature (the gong, for 
example), but it's not strictly related to voice allocation or 
anything like that; it's just a form of control data. I don't see 
what justifies making this more special than a "standardized" NOTE 
control.


> Any VOICE_CONTROL_SET for a VID that does not exist is discarded.

Or just never talk about VVIDs you haven't "initialized". Seems dead 
simple to me, since all you have to do is VOICE_ALLOCATE(vvid) at 
least once before you start using 'vvid'.

(This is where I find "VOICE_ALLOCATE" confusing. To the synth, is an 
"allocated VVID" one that currently has a physical voice, or does any 
initialized VVID count? I can see sequencer and synth coders using 
the same term for two rather different things, if the term "ALLOCATE" 
is used for this.)


> I don't think there is any instrument for which this can't work. 

Right - it's just slightly too much redundancy for my taste. ;-) 

Seriously, though; there has to be *one* of DETACH_VVID and 
VOICE_ALLOCATE. From the implementation POV, it seems to me that they 
are essentially equivalent, as both are effectively used when you 
want to say "I'll use this VVID for a new context from now on." 
VOICE_ALLOCATE is obviously closer to the right name for that action.


> It may not be a perfect fit for some, but I think they are the vast
> minority.
>
> This model fits and doesn't taste too bad.

Well, some synths may ignore VOICE_ON entirely, so I don't see why it 
deserves to be special, but that's my only real problem with this. 
Can't see a technical problem with VOICE_ON, though.


//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 ---