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