On Tuesday 07 January 2003 09.15, Tim Hockin wrote: > > 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.
Or you can tell the plugin when you want a particular VVID to be assigned to a new voice. [...] > > -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. 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. > > -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, 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.) > 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. 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. > > (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? 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. > > 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. 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 ---