W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 18764] MIDI messages don't all have a channel, and status should be part of data.

From: <bugzilla@jessica.w3.org>
Date: Mon, 10 Sep 2012 22:27:30 +0000
Message-Id: <E1TBCS2-0000K8-Sq@jessica.w3.org>
To: public-audio@w3.org

--- Comment #31 from Chris Wilson <cwilso@gmail.com> 2012-09-10 22:27:30 UTC ---
(In reply to comment #30)
> I like to think of MIDI as a protocol with variable length messages: 1 or more
> bytes per message. Which messages you send is up to the user. Drawing a hard
> line at the 3 byte boundary will penalize those sending messages with more than
> 3 bytes.

I can understand that view.  My argument was there is a serious inflection
point at 3 bytes-or-less; but again, my bigger concern is that we not, as you
put it, "penalize" those sending messages of 3 or fewer bytes (by making them
learn to create MIDIMessages and organize into arrays), not that we enforce a
hard boundary at 3 bytes.  (Although I think it's a good idea, but I think I've
beaten that horse enough by now.)

> > [sending partial messages]
> > That will be unfortunate, then, and we'll have to allow partial
> > sysex messages in MIDIMessage, a la CoreMIDI.
> I don't understand, Windows allows sending partial MIDI messages too?

Yes.  I'm just starting to think the "MIDIMessage" name might be misleading, if
it's not necessarily a complete message; but then there's the oddity in
CoreMIDI that short messages are not to be split across MIDIPackets (I don't
know if that's enforced, but it is stated in the docs), so I don't think we can
just say "arbitrary buffer of any kind of data" either.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 10 September 2012 22:27:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC