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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #16 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-08 07:07:04 UTC ---
(In reply to comment #15)
> (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
> message:
> 
> function send (data, /* optional */ timestamp) {
>   port.sendMIDIMessage({
>     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. ^^

Another thing is that it's not necessarily even an optimization for the common
case, as it doesn't have the timestamp; MIDI sequencers or anything
time-sensitive shouldn't rely on non-timestamped messages. Coincidentally, that
boilerplate function I just made allows you to have timestamps with just adding
one argument to the function call.

-- 
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:07:08 UTC