15 Jan
2003
15 Jan
'03
8:20 p.m.
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(a)olofson.net>
Does continuous control mean continuous sound?
They are not totally separate, but VOICE control is something unique to
Instruments.
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.
Unless I am musically mistaken, a glissando is not a slide. If you want to
do chord slides, you should program it as such.
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!
That is how step-sequencers work, no? You turn a note on and go about your
business. The only control events are init events.
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.
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(a)olofson.net>
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?
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. 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? 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. 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. 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...? 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? 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. 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(a)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). 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(a)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(a)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. 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