7 Jan
2003
7 Jan
'03
8:31 a.m.
On Tuesday 07 January 2003 09.15, Tim Hockin wrote:
Or you can tell the plugin when you want a particular VVID to be
assigned to a new voice.
[...]
I'm actually arguing that *no* specific event or control is the "note
on". It could be triggered by VELOCITY changes, or by any other Voice
Control or combination of Voice Controls. It's entirely synth
specific.
Well, it's not quite that simple with continous velocity
instruments... You may want to steal a voice when the velocity is
high enough, and possibly even have some other "context" steal it
back later on. (It would be the right thing to do - but if someone
actually cares to implement it is another matter. It is, after all,
little more than an emergency solution.)
Yeah, it's basically a mattor of allocation - either of a physical
voice, or a temporary "fake voice" or something else that can track
the incoming events until a physical voice is allocated.
I think different synths will want to do this in different ways, but
we need to come up with an API that's clean and works well for all
sensible methods.
Either tell the host/sender when the VVID is free (which means you
need a VVID reserve that has some sort of hard to define relation to
latency), or let the host/sender tell the synth when it no longer
cares about a specific "voice context". I strongly prefer the latter.
The problem is that voice IDs still cannot have a direct relation to
voices. If they have, you can't steal voices, since that would result
in the host/sender sending events for multiple voices using the same
ID. So, this effectively just forces the complexities of "voice
management by reference" into *both* synths and hosts/senders.
Either way, VVID allocation and voice allocation are still two
different issues. VVID is about allocating *references*, while voice
allocation is about actual voices and/or temporary voice control
storage.
//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 ---
continuous
note on a particular VVID. The sequencer only reuses a
VVID once it has ended any previous notes on that VVID. The
sequencer can allocate a
This is the current issue at hand - just because the sequencer has
ended a VVID with a voice-off, doesn't mean the voice is off. It
just begins the release phase of the envelope, on some synths.
This could take a while. Either you need to NEVER re-use a VVID, or
you need to tell the host when an ended VVID is actually re-usable.
Or you need to have voice-ids allocated by the plugin, and NOT the
host, which I like more. -HOWEVER-
there is no rule that a note has any pitch or velocity
or any other particular parameter, it is just that the Voice-On
tells the voice to start making sound and the Voice-Off tells the
voice to stop making sound.
Correct. Though David is half-heartedly arguing that maybe
Velocity is the true note-on. I disagree. -ALSO HOWEVER-
the entity which sends voice-on and off messages
may not directly refer to the object's voices. Instead, the event
sender puts
..in the currently understood VVID model.
voices to do. This differential is in place
because sequencers
typically send more concurrent notes than the plugin has actual
voices for AND the
On the contrary, hopefully you will rarely exceed the max polyphony
for each instrument.
other words, it is the role of the plugin to
decide whether or
not to steal
I believe you should always steal notes, but I suppose there will
be some instrument plugin some lunatic on here will devise that
does not follow that. Newer notes are always more important than
older notes, but if you exceed max poly, a red light should go off!
Yes! Bad things *will* happen in 99% of cases. (Whether you can
actually hear the difference in a full mix is another matter.)
(1)send
voice-on event at timestamp X. This indicates a note is
to start.
(2)send parameter-set events also at timestamp X, these are
guaranteed to
This is also for debate - David dislikes (and I agree) the notion
that you have to send a note-on but the plugin does not have enough
info to handle (for example) a velocity-mapped sampler until later.
Process events in order. So a few ideas are on the table. (4)send
voice-off event at later time to end the note and free
the voice.
And what of step-sequencing, where you send a note-on and never a
note-off? Finite duration voices (samples, drum hits, etc) end
spontaneously. Does the plugin tell the host about it, or just let
the VVID leak? When the
plugin reads the voice-on event at timestamp X it
decides whether to allocate a voice or not. If it has an
initialization routine for voice-on events, then the plugin must
read through the remaining events with timestamp X to get
initialization arguments. The plugin must delay actually
I guess it may not be tooo bad. Plugins which need some init info
(such as velocity for the velo-map) know they need this, and can
look for that info. Other plugins for whom an init event is no
different than a continuous event just go about their merry way.
But before we all decide this, I want to explore other notions.
I'm not saying my negative Voice-ID thing is great, but I rather
like the idea that Voice-Ids mean something and are almost purely
the domain of the plugin.