- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Oct 2012 08:21:22 +0000
- To: public-audio@w3.org
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