Re: MIDI proposal implemented

On Wed, May 2, 2012 at 8:16 PM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> On Wed, May 2, 2012 at 3:18 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> 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).
>>
>
> Using gUM was just my best bet at having an existing security/permissions
> model to use to ease the standardization process. I'm open to better ideas.
>

I think it's the right idea. We just need to attach the APIs you need to
MediaStream.

I agree, but the usefulness of MIDI isn't limited to those cases. Hence I
> think we should have a separate MIDI API that has integration points with
> Media Streams rather than making a lot of common use cases more complicated
> than they are on other platforms. For example having to set up a processing
> graph, possibly in another thread, just to have access to a MIDI game
> controller is not desirable.
>

Sure. Most of the APIs you want can probably be attached to a
MIDIMediaStreamTrack object, or the MediaStream itself if we want to
support dynamic device selection there for example.


>
>> 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.
>>
>
> IMHO being able to select the device is very crucial to a MIDI API. Let's
> take a DAW in a recording studio for example: there's a MIDI keyboard to
> control a synth that's being played live and recorded and in addition the
> recording engineer has a control table to interact with the user interface
> of the DAW, for play, record, rewind, save, etc. In most cases its highly
> desirable to be able to select the device, because different devices have
> different purposes.
>

Yeah. The question is how much needs to be exposed through API and how much
can be handled entirely through browser UI.

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]