Re: MIDI proposal implemented

On Wed, May 2, 2012 at 7:19 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> So, we have an experimental implementation already!  We should probably
> start drafting a spec soon, too. :)
>

I don't think we want getUserMedia to pass something that's not a
MediaStream to its callback. Besides, there's no other way to handle
getUserMedia({video:true, audio:true, midi:true}, callback).

If we specify a MIDI as a track type in MediaStreams, you get benefits such
as being able to process MIDI from audio resources loaded with an <audio>
element, keep MIDI in sync with other media types, record MIDI using
StreamRecorder, streaming MIDI over WebRTC etc, with no extra API work.

I'm still not convinced that MIDIAccess-style enumeration of MIDI devices
is something that Web browsers should support. It would be much better if
we can express the applications' requirements declaratively in parameters
to getUserMedia and let the browser handle device selection. Although it
would probably be OK to expose the MIDIDevice properties on MIDI streams
the browser has chosen to send to the application.

(BTW do you want to be able to process MIDI messages in a Worker?)

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]