W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 18764] MIDI messages don't all have a channel, and status should be part of data.

From: <bugzilla@jessica.w3.org>
Date: Fri, 07 Sep 2012 23:48:54 +0000
Message-Id: <E1TA8IA-0000SF-QD@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #14 from Chris Wilson <cwilso@gmail.com> 2012-09-07 23:48:54 UTC ---
Florian: I have to disagree.  This is a MIDI API.  MIDI is a software protocol.
 I don't think we should be explicitly trying to make this a generic serial
send/receive API.  All the wealth of devices I'm interested in out there-
synths and keyboard controllers, drum machines, mixers, guitar amp simulators,
DJ controllers, lighting systems, control pads like the Launchpad, and more
have all designed for MIDI.  I don't think we need to go out of our way - e.g.
validating every message - but we do need to design for the protocol, as timing
can be important to real-world devices.  And most importantly - this is the
point I really, really care about - we should be optimizing for the most
important and commonly-used scenarios in sending and receiving MIDI messages. 
Far and away the most common scenario is a three-byte "short" message - sysex
is useful and needed, but you end up doing a tremendous amount with just note
on/off and CC messages.

This also is my reasoning for wanting the "send a short message" call to be as
trivial as possible - send( status, data0, data1) - because it is incredibly
common.

Jussi - I disagree that "MIDI devices hardly ever transfer more than 100
messages in a second."  Or, more to the point - I can easily see wanting to be
able to have a higher-speed connection than that.  Not because I am a
high-speed-Rachmaninoff player, but because I want to be twisting knobs with
instantaneous response, and because I've seen first hand that those sexy
Ableton and Traktor controllers have multicolor button displays, and pushing
data back and forth to those could easily outstrip 100 messages/second.  I
could hit that from computer->Launchpad in my Conway demo easily, by hitting a
button twice in a second.

I understand 

port.sendMIDIMessage( { data: Uint8Array([0x80, 0x70, 0x60] ) })

is only a couple of object allocations/constructions and pushing 3 parameters
into an array (and pulling them back out) over

port.sendMessage(0x80, 0x70, 0x60)

However, as an author, it's cargo-cult boilerplate.  I think we should need to
make this ultra-common case simple.

-- 
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 Friday, 7 September 2012 23:48:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 23:48:59 GMT