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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #30 from Florian Bomers <w3c_bugz@bome.com> 2012-09-10 22:14:55 UTC ---
(In reply to comment #27)
> - but I'd also point out the whole point of those controllers (like my Livid
> CNTRLR) that use sysex for remapping is so that developers can write software
> that just deals with straight controller and key mappings, and not have to
> write the manufacturer-specific sysex.
> [...]
> See above - I think the cases when you're sending sysex are different in
> nature.  Sysex messages tend to have a lot more than a single byte identifying
> what type of message they are, and therefore will likely have to have a
> boilerplate header in the code somewhere, likely as an array, already.  Again,
> this is not my highest-priority concern.

yes, for some applications this is true, and the object form (aka
sendMIDIMessage()) makes most sense, also for MIDI Thru/filter type
applications.

But many controllers also use Sys Ex for realtime control, e.g. high-res
faders, text/graphics displays.
And MIDI Show Control! I assume those guys will love a variadic send()
function!

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.

> [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?

Anyway, another thing to consider is that the implementation needs to handle
splitting up received MIDI messages, too, if they get too big.

-- 
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:14:56 UTC