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: Tim Hockin (thockin_AT_hockin.org)
Date: Tue Jan 07 2003 - 10:15:40 EET


> 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


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 - 10:23:10 EET