[Bug 18992] Running status should be prohibited

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

--- Comment #11 from Chris Wilson <cwilso@gmail.com> ---
(In reply to comment #10)
> The fact that CoreMIDI disallows running status was already part of Yamahas
> original request to ban running status. 

Yamaha had mentioned that iOS disallowed it (but I'd point out all iOS MIDI
devices are going to be USB-MIDI devices, and USB-MIDI disallows running status
anyway).  I'd run across this mention in desktop CoreMIDI documentation.

> I don't think that a limitation on ONE system is a good enough reason to
> limit a cross platform API. I think it's more important to create an API
> that is generally useful and makes sense, than to find the common
> denominator of functionality available in today's OS's.

I don't see this as a limitation.  I think the point I'm trying to make is that
running status had a point - to compress data on an actual 31.25kB serial
connection - and that should be handled well below this API, and I don't see a
significant reason to impose having to watch out for running status and unroll
it on reception (Florian, from previous comments I *think* you agree with this
- that you should never get running status in the data bytes in a MIDI message
in the Web MIDI API).

Likewise, I don't really see a strong enough reason to support it in sending
either.  (It is not just CoreMIDI, BTW - any other system, like ChromeOS, where
the only hardware connected would be USB-MIDI, would have to unroll this also.)
 This is a tradeoff, though - Windows lets you send running status, but direct
USB-MIDI doesn't, and CoreMIDI doesn't.  On those systems, the implementations
of Web MIDI would have to parse the send() data into messages to look out for
running status before sending the data deeper down.  If necessary, we can
impose this on implementors, but:

1) If we're going to do that, we need to be explicit about requirement in the
spec ("data in the send() call may make use of MIDI running status, and
therefore implementations MUST support running status to the end device; either
by sending the running status out onto a MIDI hardware protocol wire, or
unrolling the running status (i.e. inserting additional status bytes as needed)
in the case of devices that do not support them, such as USB-MIDI devices.")

2) I still want to understand a use case/scenario that needs this.  This
doesn't mean we won't be compatible with old MIDI devices; the MIDI hardware
interface will unroll this for you, on all current systems (it's required to). 
The best I can come up with is you can read in a block in a standard MIDI file
and drop it straight into the API - but I can only come up with one scenario
(Media player) where I wouldn't need to be interpreting the message data myself
at the same time (and therefore unrolling it at the app layer anyway).

> So I think it's still the right thing to discourage running status but not
> to prohibit it. As previously said, Yamaha's concern that a receiver might
> not be able to understand running status is not reasonable. The disclaimer
> might even say that sending a message with running status might not work the
> same on all OS's. Then the CoreMIDI implementation does not need to take
> care of undoing running status, though it's really not that hard.

We need to clearly state 

1) whether running status will ever show up in the data an app may receive from
the Web MIDI API (I think we are agreed it's okay to say it does not?), and

2) whether an application can utilize running status in the send() data.  This
MUST be clearly stated - as either a MUST or a MUST NOT be supported - as it
does require parsing of the data in order to support on a sizable number of
systems (OSX/iOS and any direct-to-USB-MIDI implementation).

"Discourage" doesn't really mean anything.  :) We either say implementations
need to support it, or we say it's prohibited.  (Remember, this spec is for
implementers as well as developers using the API.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 16 November 2012 19:02:34 UTC