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: Sat, 08 Sep 2012 07:02:30 +0000
Message-Id: <E1TAF3m-0004Vt-Uu@jessica.w3.org>
To: public-audio@w3.org

--- Comment #15 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-08 07:02:28 UTC ---
(In reply to comment #14)
> 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.

Nevertheless, the bottleneck is never going to be in this part. Even
smartphones should be able to send at least hundreds of thousands of MIDI
messages this way. And really, if the underlying API makes it slower to send
completely custom messages, it's pretty easy to see the length of the typed
array in the MIDIMessage and if it's <= 3, you'll know it's a short message.

sendMessage is just sugar, not really a meaningful optimization.

> 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.

The API users will probably make boilerplate that fits them anyway, it's likely
that there will be libraries that have separate functions for common cases,
such as

noteOn(key, velocity)
noteOff(key, velocity)
controlChange(cc, value)

and they can internally use even a simple function like this for sending a

function send (data, /* optional */ timestamp) {
    timestamp: timestamp,
    data: new Uint8Array(data)

/* send the message ASAP */
send([0x80, 0x70, 0x60])
/* send the message one second later */
send([0x80, 0x70, 0x60], performance.now() + 1000.0)

In fact I intend to make a library like that myself. ^^

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 Saturday, 8 September 2012 07:02:32 UTC

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