Re: [linux-audio-dev] more on XAP Virtual Voice ID system

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] more on XAP Virtual Voice ID system
From: David Olofson (david_AT_olofson.net)
Date: Tue Jan 07 2003 - 14:25:29 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 14:36:15 EET