This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I realized I had not explicitly detailed what can go in the data bytes in a send() call. I believe this should be effectively what can go in a MIDIPacket in CoreMIDI: A variable-length stream of MIDI messages. Running status is not allowed. In the case of system-exclusive messages, a packet may only contain a single message, or portion of one, with no other MIDI events. The MIDI messages in the packet must always be complete, except for system-exclusive.
(In reply to comment #0) > I realized I had not explicitly detailed what can go in the data bytes in a > send() call. I believe this should be effectively what can go in a > MIDIPacket in CoreMIDI: > > A variable-length stream of MIDI messages. Running status is not allowed. In > the case of system-exclusive messages, a packet may only contain a single > message, or portion of one, with no other MIDI events. The MIDI messages in > the packet must always be complete, except for system-exclusive. Sounds good to me.
Fixed by https://dvcs.w3.org/hg/audio/rev/e0f3c5871603. I actually made it "complete messages only" - i.e. sysex messages must be complete as well. Without this stricture, we would have to be more explicit about the state of the MIDI message handler (i.e., if a partial message was the last thing received, we would need to know that the next message has no valid MIDI header byte). From previous discussion, I don't believe we decided we really needed partial sysex; if so, please open another bug to track.
Seeing no objection. Closing.