[Bug 18992] Running status should be prohibited

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

--- Comment #5 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-10-03 08:21:21 UTC ---
(In reply to comment #4)
> Running Status is not just a convention, it's part of the core MIDI
> specification. Every MIDI receiver should understand running status or it will
> risk misinterpreting the incoming data. This is particularly true for 5-pin DIN
> MIDI connections (which are not obsolete).
> 
> For example, my old drum computer sends 5 bytes for every pad: e.g. this string
> of MIDI hex bytes: "90 40 7F 40 00", turning a note on and immediately off --
> consecutive notes on the same channel, it will also omit the first status byte.
> For fast and "dense" rhythm patterns, the byte savings will improve timing
> considerably.

I'm too young and spoiled with bandwidth to understand. ^^ Kidding aside, I can
see the benefit of Running Status.

> All software API's that I know of will undo running status for the user. That's
> probably appropriate for the Web MIDI API, too. But "prohibit" sending running
> status seems quite arbitrary to me. If supported by the underlying OS support,
> running status can be passed on to the MIDI interface with its positive
> implications. Otherwise, the Web MIDI API implementation needs to undo running
> status to fulfill the underlying OS' requirements. That's not hard to do.
> 
> In a nutshell: only because some transports and some OS API's do not want
> to/need to handle running status, it does not mean that the Web MIDI API should
> prohibit it entirely. Discouraging its use is OK.

Agreed.

Something I'm wondering (maybe a bit off-topic) is that I have a few
MIDI->USB-MIDI adapters, how do these deal with running status? I assume the
adapter just adds the missing bytes?

-- 
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 Wednesday, 3 October 2012 08:21:23 UTC