Re: Questions on data in MIDIPackets
Re: Questions on data in MIDIPackets
- Subject: Re: Questions on data in MIDIPackets
- From: Kurt Bigler <email@hidden>
- Date: Tue, 19 Feb 2002 21:45:42 -0800
on 2/18/02 8:47 PM, Doug Wyatt <email@hidden> wrote:
>
I should mention, the MIDIServer's scheduler, when asked to schedule
>
multiple events at the same time, will *always* play them in the order
>
they were scheduled.
>
>
Consider a 14-bit parameter change or a simultaneous note-on/note-off
>
pair -- if these events are re-ordered, the stream is not what the
>
sender intended.
>
>
IMHO, the probability of multiple clients scheduling events for the
>
precise same MIDITimeStamp is so small as not to be worth considering,
>
and thus the client, knowing that the scheduler is FIFO for events at
>
the same time, can effectively make its own choices about event priority
>
without the MIDI API having to be complicated by this detail.
I don't understand the MIDIServer yet, so maybe my comments are green, but I
just want to interject a reminder of a useful midi-processing feature.
I think the feature is called "following" - where the user plays some notes
on a keyboard, and some hardware or software automatically generates
(inserts into the same stream) additional notes possibly simultaneous with
the played notes, but say for example, an octave higher.
(Skip this paragraph for a quick read.)
I'm not sure of its general relevance but being an organist I have
implemented for myself some midi stuff that emulates control structures
similar to what pipe organs typically have, including what is called "octave
couplers" which automatically play notes an octave higher for example. So
on a pipe organ if you have the "unison" (normal playing) coupler on and the
"4-foot" (octave higher) coupler on then when you plan one key you get two -
the one you asked for and the next octave higher. So if you play two keys
an octave apart then how many sounding notes do you get? Answer: 3. 3
notes spanning two octaves. The middle note is "on twice" once by being
played manually as the higher note, and once by being an octave higher than
the manually played lower note. On a pipe organ a pipe is either on or off,
and does not get twice as loud for being "on twice". So 4 logical note-ons
leads to 3 notes actually playing, because of a colission between a played
note and an automatically generated note.
So this brings up a potential problem when automatically generated notes may
"collide" with manually played notes in the same MIDI stream on the same
channel. I don't know whether the MIDI spec covers this, but for my
application I chose to permit multiple note-ons and have the sound synthesis
module keep a note-on count for each instantiated voice. Only when the the
number of note-offs equals the number of previous note-ons does the note
stop sounding. Multiple note-ons for the same note# re-trigger the same
voice (which keeps a count) rather than triggering multiple voice instances.
So if the MIDIServer might permit things like attaching modules that perform
filtering functions on a midi stream, like "simulateous octave following",
then therr might be some design issues to iron out. If the generated
logically simultaneous notes are inserted in the stream later because they
were generated later, then this might produce an audible delay between the
manually played notes and the automatic intended-to-be-simultaneous notes.
In that case keeping the stream sorted by time might be a good idea.
The other issue is of course that I would hope that neither the MidiServer
nor any standard plug-in components should over-interpret note-ons and
note-ofs (implicitly deciding that note-on counting is not a valid thing to
do and doing something like eliminating redundant note-offs), because this
would limit the flexibility of how the system could be used.
You may think of some things I haven't thought of, but I wanted to bring
midi-filtering/following into the arena of discussion.
Thanks,
Kurt Bigler
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.