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

[Tim Hockin]

Paging David, David are you there?  I'm bored - send me more arguments!!

> 
> > > I personally find this notion bizarre and counter-intuitive.  The
> > > idea that the note is turned on by some random control is just
> > > awkward.  I'm willing to concede it, but I just want to be on the
> > > record that I find it bizarre.
> 
> > The way I see it, this "random control" that triggers a note is 
> > equivalent to MIDI NoteOn. It can even be a standardized NOTE control 
> > that all synths must respond to, one way or another.
> 
> OK - in my own notes I had been referring to it as the VOICE control.  You
> send the VOICE control a VOICE_ON message and a VOICE_OFF message, or
> simpler send 0 and 1.
> 
> > > comprehend, and more consistent. I want to toss MIDI, but not
> > > where the convention makes things easy to understand.  I think that
> > > explaining the idea that a voice is created but not 'on' until the
> > > instrument decides is going to confuse people.  Over engineered. 
> > 
> > I think the alternative would render continous control synths even 
> > more confusing. "Why do I have to send a VOICE_ON to make the synth 
> > work at all?"
> 
> > Anyway, it's really an implementation issue. Just don't mention it in 
> > the API docs. Just say that the NOTE control corresponds to MIDI 
> > NoteOn/Off. Problem solved!
> 
> So stroking the NOTE control in your mind is *identical* to sending a 1 to
> the VOICE control in my mind.
> 
> > > The plugin CAN use the VVID table to store flags about the voice,
> > > as you suggested.  I just want to point out that this is
> > > essentially the same as the plugin communicating to the host about
> > > voices, just more passively.
> > 
> > Only the host can't really make any sense of the data.
> 
> If flags are standardized, it can.  Int32:  0 = unused, +ve = plugin owned,
> -ve = special meaning.
> 
> > > It seems useful.
> > 
> > Not really, because of the latency, the polling requirement and the
> > coarse timing.
> 
> When does the host allocate from the VVID list?  Between blocks.  As long as
> a synth flags or releases a VVID during it's block, the host benefits from
> it.  The host has to keep a list of which VVIDs it still is working with,
> right?
> 
> > > If the plugin can flag VVID table entries as released, the host can
> > > have a better idea of which VVIDs it can reuse.
> > 
> > Why would this matter? Again, the host does *not* do physical voice 
> > management.
> > 
> > You can reuse a VVID at any time, because *you* know whether or not 
> > you'll need it again. The synth just doesn't care, as all it will 
> 
> right, but if you hit the ned of the list and loop back to the start, you
> need to find the next VVID that is not in use by the HOST.  That can include
> VVIDs that have ended spontaneously (again, hihat sample or whatever).  The
> host just needs to discard any currently queued events for that (expired)
> VVID.  The plugin is already ignoreing them.
> 
> > > > This is where the confusion/disagreement is, I think: I don't
> > > > think of this event as "INIT_START", but rather as
> > > > "CONTEXT_START". I don't see the need for a specific "init" part
> > > > of the lifetime of a context. Initialization ends whenever the
> > > > synth decides to start playing instead of just tracking controls.
> > >
> > > Right - this is the bit I find insane.  From the user perspective: 
> > > I want to start a note.  Not whenever you feel like it.  Now.  Here
> > > are the non-default control values for this voice.  Anything I did
> > > not send you, assume the default.  Go.
> > 
> > So, bowed string instruments, wind instruments and the like are 
> > insane designs? :-)
> 
> No, they just might not have init params.  The voice is started when the bow
> contacts the string.
> 
> > A bowed string instrument is "triggered" by the bow pressure and 
> > speed exceeding certain levels; not directly by the player thinking 
> 
> Disagree.  SOUND is triggered by pressure/velocity.  The instrument is ready
> as soon as bow contacts the string.
> 
> > > The difference comes when the host sends the 'magic' start-voice
> > > control too soon.
> > >
> > > Assume a synth with a bunch of init-latched controls.
> > > Assume velocity is the 'magic trigger'.
> > > time0: Host sends VOICE_START/ALLOC/whatever
> > > time0: Host sends controls A, B, C  (latched, but no effect from
> > > the synth) time0: Host sends control VELOCITY (host activates
> > > voice)
> > > time0: Host sends controls D, E, F (ignored - they are
> > > init-latched, and init is over!)
> > >
> > > Do you see the problem?
> > 
> > No, I see a host sending continous control data to an init-latched 
> > synth. This is nothing that an API can fix automatically.
> 
> Ok, let me make it more clear.  Again, same example.  The host wants to send 
> 7 parameters to the Note-on.  It sends 3 then VELOCITY.  But as soon as
> VELOCITY is received 'init-time' is over.  This is bad.  The host has to
> know which control ends init time.  Thus the NOTE/VOICE control we seem to
> be agreeing on.
> 
> > Yes, it has to be triggered by a standardized control, so hosts 
> > and/or users will know how to hook synths up with sequencers, 
> > controllers and other senders.
> 
> Precisely.
> 
> > If it has no voice controls, there will be no VVIDs. You can still 
> > allocate and use one if you don't want to special case this, though. 
> > Sending voice control events to channel control inputs is safe, since 
> > the receiver will just ignore the 'vvid' field of events.
> 
> I think that if it wants to be a synth, it understands VVIDS.  It doesn't
> have to DO anything with them, but it needs to be aware.  And the NOTE/VOICE
> starter is a voice-control, so any Instrument MUST have that.
> 
> > > > has killed the voice. Thus, no need for a "VOICE_END" or similar
> > > > event either.
> > >
> > > The host still has to be able to end a voice, without starting a
> > > new one.
> > 
> > Why? What does "end a voice" actually mean?
> 
> It means that the host wants this voice to stop.  If there is a release
> phase, go to it.  If not, end this voice (in a plugin-dpecific way).
> Without it, how do you enter the release phase?
> 
> > >From the sender POV:
> > 	I'm done with this context, and won't send any more events
> > 	referring to it's VVID.
> 
> No.  It means I want the sound on this voice to stop.  It implies the above,
> too.  After a VOICE_OFF, no more events will be sent for this VVID.
> 
> > >From the synth POV:
> > 	The voice assigned to this VVID is now silent and passive,
> 
> More, the VVID is done.  No more events for this VVID.  The reason that
> VVID_ALLOC is needed at voice_start is because the host might never have
> sent a VOICE_OFF.  Or maybe we can make it simpler:
> 
> Host turns the NOTE/VOICE on.
> It can either turn the NOTE/VOICE off or DETACH it.  Here your detach name
> makes more sense.  A step sequencer would turn a note on, then immediately
> detach.
> 
> > assumed to be more special than it really is. NOTE/VOICE_ON/VOICE_OFF 
> > is a gate control. What more do you need to say about it?
> 
> Only if you assume a voice lives forever, which is wasteful.  Besides that,
> a gate that gets turned off and on and off and on does not restart a voice,
> just mutes it temporarily.  Not pause, not restart - mute.
> 
> > > control. But until then we need a consistent way to handle
> > > init-latched controls. Because they ARE special.  They all need to
> > > be sent before the voice is activated.
> > 
> > Yes - just like you have to send MIDI Program Change *before* playing 
> > notes. It's not really a continous control, but MIDI sequencers don't 
> > special case it, since it's obvious enough that the user should say 
> > what sound he/she wants *before* starting to play.
> 
> Well, you CAN change Program any time you like - it is not a per-voice
> control.
> 
> > > YES!  The same as a VOICE_ON. or send a 1 to the VOICE control. 
> > > Describe it how you will, it tastes like VOICE_ON.  Remember before
> > > when I said I would concede this point?  I lied!  I might concede
> > > VVIDs and give up on plugin-allocated VIDs, but this seems more and
> > > more right, and you yourself talked me back into it.
> > 
> > Well, then we can probably conclude that most of this is a matter of 
> > terminology confusion. :-)
> 
> MOSTLY.  We still have agree on the problem of init- and release-latched
> controls. See below.
> 
> > Either way, what I'm trying to figure out is a way to have both 
> > note-on latched and continous control synths do sensible things even 
> > if the sender doesn't know which type it's dealing with.
> 
> Of course.  See below again :)
> 
> > > I don't like
> > > that.  Perhaps release velocity is a different control.
> > 
> > Yes, I think so.
> 
> Release velocity is a release-latched control.
> 
> Control set events can have three forms (a control can handle any
> combination of them by flags or something):
> 
> 1) events that apply to the starting of the voice
> 2) events that apply to an active voice
> 3) events that apply to the ending of an event
> 
> Controls which are init-latched ONLY (e.g. velocity for a velo map) need to be
> grouped together before the voice is started.
> 
> Controls which are release-latched ONLY (e.g. release velocity) need to be
> grouped together before the voice is ended.
> 
> We need to standardize the way of sending these.
> 
> Idea 1:  as we've been discussing, have some window during which events are
> KNOWN to be init (or release).
>  -- INIT:
>       send VOICE_INIT(new_vvid)  /* declare a vvid */
>       send SET(new_vvid, ctrl) /* set controls for init */
>       send VOICE_ON(new_vvid) /* start the vvid */
>  -- RELEASE:
>       send VOICE_DEINIT(vvid) /* going into release */
>       send SET(vvid, ctrl) /* set controls for release */
>       send VOICE_OFF(vvid) /* do release */
> 
> 
> Idea 2:  similar to idea 1, but less explicit.
>  -- INIT:
>       send SET(new_vvid, ctrl) /* implicitly creates a voice */
>       send VOICE_ON(new_vvid) /* start the vvid */
>  -- RELEASE:
>       send SET(new_vvid, ctrl) /* send with time X */
>       send VOICE_OFF(vvid) /* also time X - plug 'knows' it was for release */
> 
> 
> Idea 3:  different events for init/release/active sets.
> 
> 
> Of those, I like #1.  It feels familiar.  You declare a variable before you
> use it, and you unlink something before you kill it.
> 
> #2 init is ok.  I don't like the release.  #3 is not pretty.
> 
> 
> 
> we're gettig there...
> Tim
>