- From: <bugzilla@jessica.w3.org>
- Date: Mon, 01 Oct 2012 08:34:35 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18992 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 considerably. 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