Re: Questions on data in MIDIPackets
Re: Questions on data in MIDIPackets
- Subject: Re: Questions on data in MIDIPackets
- From: Herbie Robinson <email@hidden>
- Date: Wed, 13 Feb 2002 00:59:33 -0500
I generally agree with Brian's statements.
... and sequencers certainly shouldn't preserve (slow) MIDI timings when
playing back on higher resolution interfaces such as USB.
I agree in principle with this, too. If I can shove 20 notes into a single
1ms USB Frame because they were intended to all play on the downbeat of the
bar, then I should do so.
If those notes are being sent to a synth with built in USB interface, then
the synth will receive them all at the same time and should play them all as
quickly as possible (ideally all at the same time). Hopefully the synth's
ability to parse and play the notes is better then the speed of classic
MIDI.
Actually, the driver could pass the events on to the device ahead of
time with time stamps (assuming the device's firmware can be
upgraded). This could actually allow devices with less CPU power get
much better timing.
If those same 20 notes were being sent to a USB interface with a classic
MIDI output, then the interface will have to send them all as quickly as
possible within the classic MIDI speed (recognizing that the classic MIDI
limitation will be a bottleneck).
There probably needs to be some attributes on the endpoints that
specify the transmission delays. Then the application can correct
for them if it wants to. It's probably not a good idea to have
drivers try and correct for MIDI delays, because the algorithm can
get somewhat complex and would require constant re-computation
because the driver doesn't see all the data. The application can
adjust for transmission (and other) timing delays as edits are being
done. Attributes would be per character time, whether or not running
status is used and possible some info about whether the device can
respond to incomplete Events..
System Exclusive is an exception (as it often is). I'm not saying we
shouldn't speed up delivery of Sys.Ex.; I love the idea of quickly sending a
large Sys.Ex. message over a high speed bus. But it can cause problems in
some cases (my experience is on USB):
1. There are some devices that expect to receive Sys.Ex. with particular
timing. Speeding up the delivery of the data can cause the communication to
fail if particular timing is expected.
2. High speed interfaces like USB can transfer enough to data to quickly
fill the input buffers of a device with built in USB interface. MIDI devices
have never had to be able to receive and parse data at anywhere near the
rate of USB. This is a challenge to device manufacturers, larger buffers and
faster processors are required to truly take advantage of USB speed. Sys.Ex.
is a worst case scenario with largest packet sizes and often with complex
parsing/processing required. The buffers and processing speed necessary to
handle high speed Sys.Ex. might tend to be unreasonable overkill for
handling all other MIDI data 99% of the time. So such devices might tend to
NAK high speed Sys.Ex. transactions on a regular basis.
It would be a good idea to have a separate pipe for SysEx so that
flow controlling for SysEx won't block other MIDI events. Either
that or some sort of out of band credit system so that SysEx will
never invoke flow control at the USB level.
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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.