> 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. > My underlying assumptions are: I made a post a while back defining all the XAP terminology to date. Read it if you haven't - it is useful :) > -DEFINITION: the individual voices produce finite periods of sound which we > call notes. A note is the sound that a voice makes between a Voice-On event > and a Voice-Off event (provided that the voice is not reappropriated in the > middle to make a different note) We've been avoiding the word 'note' because it is too specific. The lifetime of voice is either finite or open-ended. A synth would be open-ended. A gong hit would be finite. > -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! > (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. Tim
