7 Jan
2003
7 Jan
'03
8:47 a.m.
On Tuesday 07 January 2003 10.19, Steve Harris wrote:
Why?
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.
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 ---
On Tue, Jan 07, 2003 at 03:21:22 +0100, David Olofson
wrote:
[...]
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.
> > 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? > > 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. 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...) 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.