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:14:55 +0000
Message-Id: <E1TBCFr-0008F7-Ma@jessica.w3.org>
To: public-audio@w3.org

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

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()

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

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