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

[David Olofson]

On Tuesday 07 January 2003 10.19, Steve Harris wrote:
> On Tue, Jan 07, 2003 at 03:21:22 +0100, David Olofson wrote:
> > > > Problem is step 1. If the voice allocator looks at velocity,
> > > > it won't work, since that information is not available when
> > > > you do the allocation. Likewise for setting up waveforms with
> > > > velocity maps and the like.
>
> But in the general case this is just mapping to parameters, you
> have to be able to handle parameter changes during the run of the
> instrument, so why not at creation time too?
[...]

Yeah, byt you may not want control values to be latched except when a 
note is actually triggered (be it explicitly, or as a result of a 
contro change). Also, this voice.set_voice_map() may have significant 
cost, and it seems like a bad idea to have the API practically 
enforce that such things are done twice for every note.


> > > > 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.
> > >
> > > So maybe VOICE creation needs to be a three-step process.
> > > * Allocate voice
> > > * Set initial voice-controls
> > > * Voice on
>
> I think this is harder to handle.

Why?


> > >  This is essentially saying that initial parameters are
> > > 'special', and they are in many-ways (I'm sure velocity maps
> > > are just one case).
> >
> > Yes; there can be a whole lot of such parameters for percussion
> > instruments, for example. (Drums, cymbals, marimba etc...)
>
> I still dont think there special. Velicty maps only behave this way
> in midi because you cant change velovity during the note in midi,
> you still need to be able to call up the map instantly, so it
> doesn't matter if you dont know the map at the point the note is
> 'created'.

It's just that there's a *big* difference between latching control 
values when starting a note and being able to "morph" while the note 
is played... I think it makes a lot of sense to allow synths to do it 
either way.


> > > Or we can make the rule that you do not choose an entry in a
> > > velocity map until you start PROCESSING a voice, not when you
> > > create it.  VOICE_ON is a placeholder.  The plugin should see
> > > that a voice is on that has no velocity-map entry and deal with
> > > it whn processing starts.  Maybe not.
> >
> > No, I think that's just moving the problem deeper into synth
> > implementations.
>
> Why? You can create it with the map for velocity=0.0 or whatever,
> and change it if needed. This seems like it will lead to cleaner
> instrument code.

Cleaner, maybe, but slower and more importantly, incorrect.

Bad Things(TM) will happen if you happen to play a "note-on latched 
velocity" synth with data that was recorded from a continous velocity 
controller, for example. What are you supposed to do with the 
sequenced data (or real time input, for that matter!) to have correct 
playback? I don't like the idea of having two different *types* of 
controls (continous and "event latched") for everything, just to deal 
with this.
 

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