Subject: Re: [linux-audio-dev] more on XAP Virtual Voice ID system
From: David Olofson (david_AT_olofson.net)
Date: Tue Jan 07 2003 - 14:41:43 EET
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 ---
This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 14:46:17 EET