Hi all. I joined the list today, and have been following the
vivid discussion on VVIDs with interest. On the whole, I agree
with David Olofson. There are a number of limitations in the
MIDI protocol and it should not be the model for any new API.
David Olofson writes:
On Wednesday 15 January 2003 14.46, Steve Harris
wrote:
[...]
> > > Starting a new note on a VVID when a previous note is still in
> > > the release phase would cause a glisando, while if the VVID has
> > > no playing voice, one would be activated and started as needed
> > > to play a new note. The sender can't reliably know which action
> > > will be taken for each new note, so it really *has* to be left
> > > to the synth to decide. And for this, the lifetime of
> > > VVIDs/contexts need to span zero or more notes, with no upper
> > > limit.
> >
> > I don't follow you at all - a new note is a new note. If your
It's not always that simple (see below).
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...?
...
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.
As an example, consider what happens when a violin player changes
the note he's playing while remaining on the same string. If he would
play the second note on another string, the transition would sound
completely different.
Using the terminology of the present discussion, what you want is that
the VVID that was playing A should get the NOTE ON event and all
associated parameters for B. What exactly it will do depends on the
patch, the current state of A, and the parameters for B. The essential
point is that whatever generates B should be aware of the relation
with A.
One a mono synth you can do this sort of thing, event with MIDI,
because the relation is implicit. With polyphonic MIDI, it't
impossible, except in some cases, and as was pointed out before,
if you repeat the same note.
So the association between VVIDs and notes should be made by the
player (caller), not by the instrument (plugin).
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.
Yes, I think you want all sound generating things to shut up if you
send stop all, not just note based things.
That depends on what kind of setup you have. If you're running
monitor sound through the software, stopping all effects means all
monitor sound dies when you stop the sequencer. This applies whether
you're monitoring external audio or output from synths, and it just
doesn't seem logical to me. Stopping the sequencer is in no way
equivalent to killing the whole net, IMNSHO, and whether or not some
hosts will still do this, the API should definitely not enforce it.
There should obviously be some sort of "panic button" feature *as
well*, but I don't see why it makes any sense to hardwire it from the
sequencer "stop button". "All Notes Off", "Stop All Sound"
and the
like are emergency features that are not used normally.
Again I tend to agree with David. Stopping the stream of events should
not imply that all sounds stop, even if this may be what you want most
of the time.
--
Fons Adriaensen
Alcatel Space