W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 18992] Running status should be prohibited

From: <bugzilla@jessica.w3.org>
Date: Mon, 01 Oct 2012 08:34:35 +0000
Message-Id: <E1TIbSV-0007Fp-Jc@jessica.w3.org>
To: public-audio@w3.org

Florian Bomers <w3c_bugz@bome.com> changed:

           What    |Removed                     |Added
                 CC|                            |w3c_bugz@bome.com

--- Comment #4 from Florian Bomers <w3c_bugz@bome.com> 2012-10-01 08:34:35 UTC ---
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

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.

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, 1 October 2012 08:34:37 UTC

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