[linux-audio-dev] Catching up with XAP

Tim Hockin thockin at hockin.org
Wed Jan 15 19:23:15 UTC 2003


I'm breaking these into two emails for the two subjects.  I'm replying to
each subject in  big reply - so you can see the evolution of my position :)

*** From: David Olofson <david at olofson.net>
> > The trigger is a virtual control which really just says whether the
> > voice is on or not.  You set up all your init-latched controls in
> > the init window, THEN you set the voice on.
> 
> The only problem I have with it is that it's completely irrelevant to 
> continous control synths - but they can just ignore it, or not have 
> the control at all.

Does continuous control mean continuous sound?

> > This is not at all what I see as intuitive.  VOICE is a separate
> > control used ONLY for voice control.  Instruments have it.  Effects
> > do not.
> 
> There's this distinct FX vs instrument separation again. What is the 
> actual motivation for enforcing that these are kept totally separate?

They are not totally separate, but VOICE control is something unique to
Instruments.

> > > What might be confusing things is that I don's consider "voice"
> > > and "context" equivalent - and VVIDs refer to *contexts* rather
> >
> > I disagree - a VVID refers to a voice at some point in time.  A
> > context can not be re-used.  Once a voice is stopped and the
> > release has ended, that VVID has expired.
> 
> Why? Is there a good reason why a synth must not be allowed to 
> function like the good old SID envelope generator, which can be 
> switched on and off as desired?

They still can - it's just the responsibility of the synth to know this, and
not the sequencer or user.

> Also, remember that there is nothing binding two notes at the same 
> pitch together with our protocol, since (unlike MIDI) VVID != pitch. 
> This means that a synth cannot reliably handle a new note starting 
> before the release phase of a previous pitch has ended. It'll just 
> have to allocate a new voice, completely independent of the old 
> voice, and that's generally *not* what you want if you're trying to 
> emulate real instruments.

ack!  So now you WANT old MIDI-isms?  For new instruments (which do not want
to feel like their MIDI brethren) this is EXACTLY what we want.  For
instruments which are supposed to behave like old MIDI synths, that is the
responsibility of the synth to handle, NOT the API or sequencer or user.

> For example, if you're playing the piano with the sustain pedal down, 
> hitting the same key repeatedly doesn't really add new strings for 
> that note, does it...?

But should we force that on the API?  No, we should force that on the synth.

> And when you enter the release phase? If have yet to see a MIDI synth 
> where voices stop responding to pitch bend and other controls after 
> NoteOff, and although we're talking about *voice* controls here, I 
> think the same logic applies entirely.
> 
> Synths *have* to be able to receive control changes for as long as a 
> voice could possibly be producing sound, or there is a serious 
> usability issue.

OK, I'll buy this.  A VOICE_OFF does not automatically mean no more events.
I can deal with that.

> >  If your
> > instrument has a glissando control, use it.  It does the right
> > thing.
> 
> How? It's obvious for monophonic synths, but then, so many other 
> things are. Polyphonic synths are more complicated, and I'm rather 
> certain that the player and/or controller knows better which not 
> should slide to which when you switch from one chord to another. 
> Anything else will result in "random glisandos in all directions", 
> since the synth just doesn't have enough information.

Unless I am musically mistaken, a glissando is not a slide.  If you want to
do chord slides, you should program it as such.

> > Reusing a VVID seems insane to me.  It just doesn't jive with
> > anything I can comprehend as approaching reality.
> 
> MIDI sequencers are reusing "IDs" all the time, since they just don't 
> have a choice, the way the MIDI protocol is designed. Now, all of a 
> sudden, this should no longer be *possible*, at all...?

I don't see what it ACHIEVES besides complexity.  This is twice in one email
you tout MIDI brokenness as a feature we need to have.  You're scaring me!

> Either way, considering the polyphonic glisando example, VVIDs 
> provide a dimension of addressing that is not available in MIDI, and 
> that seems generally useful. Why throw it away for no technical (or 
> IMHO, logical) reason?

I had a sleep on it, and I am contemplating adjusting my thought processes,
but your glissando example is not helping :)

> > Stop button is different than not sending a note-off.  Stop should
> > automatically send a note-off to any VVIDs.  Or perhaps more
> > accurately, it should send a stop-all sound event.

I was wrong - it should NOT send a stop-all.  It should stop any notes it
started.  MIDI, line-in monitoring, etc should not stop, or should have a
different stop button.

> I disagree. I think most people expect controls to respond during the 
> full duration of a note; not just during an arbitrary part of it. 
> This is the way MIDI CCs work, and I would think most MIDI synths 
> handle Poly Pressure that way as well, even though most controllers 
> cannot generate PP events after a note is stopped, for mechanical 
> reasons. (It's a bit hard to press a key after releasing it, without 
> causing a new NoteOn. :-)

I think my proposal FULLY maps to MIDI.  That said, I can accept that you
want to send voice controls during the release phase.

> >   2) The step-sequenced note:
> 
> This completely eliminates the use of voice controls together with 
> step sequencers. What's the logic reasoning behind that?

That is how step-sequencers work, no?  You turn a note on and go about your
business.  The only control events are init events.

> > It's cute.  I like it a lot.
> 
> It's just that it can't do things that people expect from every MIDI 
> synth, just because VVID allocation is integrated with the VOICE 
> control.

I don't buy this.  MIDI pitch bend is a channel control, it would still work.
Anything you can do to a MIDI synth you can do in this model.  It leaves
exact emulation of MIDI brokenness to the synth, where it belongs.

> Quite possible, unless it's legal to use VOICE as a continous 
> control. If it isn't, continous control synth simply won't have a use 
> for VOICE control input, but will rely entirely on the values of 
> other controls.

Voice is not a continuous control - it says "Go" and "Stop".  That is all.

I see four main classes of instruments:

1) always-on - this includes noise generators (record-player emu) and
monitors (line-in is always on).  The instruments would not have a VOICE
control.  They are just always on (maybe they have a mute button - not an
explicit part of the API).  They do not need VVIDs at all.  They do not have
voice controls.

2) continuous control - this includes things like a violin, which receives
streams of parameters.  This gets a VVID for each new voice.  If you want
glissando, you would tell the violin synth that fact, and it would handle
it.

3) synths - they probably latch some controls at init, and have some
continuous controls.  They get a VVID for each new voice.

4) drum-machines - this is really just a special case of #3.  Synths with
short holds are the same.  They get a new VVID for every voice.

In all cases except #1, the sequencer loads up all the init-parameters and
says 'Go'.

> Also, as soon as you want to indicate that a new note is to be played 
> on the same string as a previous not, or directly take over and 
> "slide" the voice of a previous note to a new note, you'll need a way 
> of expressing that. I can't think of a more obvious way of doing that 
> than just using the same VVID.

I'd rather see us codify a slide model.  What I'm not grasping is HOW does
the host know whether to re-use a VVID or not?  It also means that synths
need to handle both cases.

> I've often found myself missing the advantages a monophonic patches 
> have WRT note->note interaction, when using polyphonic patches. I 
> actually think the ability to eliminate this distinction is a major 
> feature that comes with VVIDs. If you can reuse VVIDs, a poly synth 
> effectively becomes N monosynths playing the same patch - if you want 
> it to. If not, just reassign a VVID for each new note.

But how does a synth request this behavior?  I don't see why this is
advantageous, or how it could be anything but confusing.

> Further, is there *really* any sense in using latched controls with 
> continous control synths? Considering that such controls are usually 
> for velocity mapping and the like, the cases where it would be of any 
> use at all in a continous control synth are probably very few, if 
> there are any at all.

Would you please explain to me what you mean by a continuous control synth?
Maybe I am just Not Getting It?  I had been assuming that a continuous
control synth was simply a synth that had all it's voice controls
dynamically updateable.  Am I missing something?



*** From: Steve Harris <S.W.Harris at ecs.soton.ac.uk>
> > This is not at all what I see as intuitive.  VOICE is a separate control
> > used ONLY for voice control.  Instruments have it.  Effects do not.
> 
> I would say only polyphonic instruments have VOICE control. Modualar synths
> are not polyphonic (at the module level).

Mono-synths need a VOICE, too.  Modular synth modules might not.  They are
effectively ON all the time, just silent because of some other control.
This works for modular-style synths, because they are essentially pure
oscillators, right?  Mono-synths can still have init-latched values, and
releases etc.  Does it hurt anything to give modular synths a VOICE control, 
if it buys consistency at the higher levels?  Maybe - I can be swayed on
that.  But a modular synth is NOT the same as just any mono-synth.




*** From: David Olofson <david at olofson.net>

> If you're *real* lazy, you can just treat new notes while the voice 
> is playing by restarting the envelopes. Given that you handle pitch 
> in the usual way (ie as continous pitch - like MIDI pitch + pitch 
> bend, basically), you get primitive legato when reusing VVIDs. Pretty 
> much a free bonus feature.

Re-using VVIDs for slides is the first thing I have heard that makes me
think it might be sane.  It is sane to me because the user decides he wants
a slide, not because the synth wants to feel like it's MIDI counterpart.

> The common logic here is that the current state of the context 
> effectively becomes parameters for the new note - and this applies to 
> both mono and poly synths.

OK - this I'll buy IN THE CONTEXT OF A SLIDE.


*** From: David Olofson <david at olofson.net>
> [...polyphony, glisando, reusing VVIDs etc...]
> > One thing you can't express with (polyhonic) MIDI is the following
> > : Suppose you have a note A playing, and you want to start another
> > one (B) 'in the context of A'. What this means is that B will
> > probably (but not necessarily) terminate A, and that the attack
> > phase of B will be influenced by the fact that it 'replaces' A.
> > This may be a glissando, but it could be something much more
> > complicated than that.

This is actually a good explanation, and one that makes sense to me (Sorry
David :)  I'm still not sure how it would be used, or what makes it valuable.

*** From: David Olofson <david at olofson.net>
> > > I don't follow you at all - a new note is a new note.  If your
> > > instrument has a glissando control, use it.  It does the right
> > > thing.  Each new note gets a new VVID.
> >
> > I agree with Tim about this.
> 
> What I'm not getting is how this is supposed to work with polyphonic 
> synths. Or isn't it, just because it doesn't really work with MIDI 
> synths...?

I don't follow you at all - what DOESN'T work?

> Why enforce that notes on polyphonic synths are completely unrelated, 
> when they're not on monophonic synths, and don't have to be on 
> polyphonic synths either? The *only* reason why MIDI can't do this is 
> that it abuses note pitch for VVID, and we don't have that 
> restriction - unless we for some reason decide it's just not allowed 
> to make use of this fact.

This does not parse well.  The whole point of polyphonic synths (in my mind)
is that every note is completely unrelated to every other note.  You can hit
middle-C 10 times and have it play ten voices of middle-C.  To say that a 
mono-synth has related voices is inane.  It has one voice.  When you want a
new voice, you have to stop the old one.

Now, I am coming around that it is not so insane to want to re-trigger a
voice, using the existing state of controls.  HOWEVER, I see this more as
a shortcut to actually sending the control values for a new voice.  I can't
see where it is actually useful beyond what I have described (and the bits I
have agreed to change).


Summary:

This is where I am on this topic now:

Two basic kinds of instruments: Always-On and Voiced.

Always-On instruments (e.g. a line-in monitor) do not have a VOICE control.
The host must always gather data from these for every processing cycle.
They do not deal with VVIDs at all.

Voiced instruments (e.g. a mono-synth or a poly-synth) have a VOICE control.
They can only make sound in response to a VOICE_ON event.  They deal with
VVIDs.

A typical voice cycle:
* send a series of 0 or more control events for VVID 'v'
  - the new voice is allocated and controls tracked
* VOICE_ON for VVID 'v'
  - the voice can now make noise
* send a series of 0 or more control events for VVID 'v'
  - the controls are actuated
* VOICE_OFF for VVID 'v'
  - the voice is sent to the release phase
* send a series of 0 or more control events for VVID 'v'
  - the controls are tracked
  - the voice can end
* VVID_RELEASE for VVID 'v'

The best way to discuss this then is a proper voice-state diagram, and I
hate ASCII drawing :)

I'm not conviced that re-using a context is useful at all.  But I don't see
why it should be excluded.  I think it adds complexity to synths - they now
have to handle this.

Look for another email later regarding latched events, which will possibly
modify all this a bit.

Sorry if this isn't the most coherent email - I lost half of it in a stupid
mistake, and the rest has been written all throughout the day.

Tim



More information about the Linux-audio-dev mailing list