Re: MIDI proposal implemented

On Wed, May 2, 2012 at 3:24 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> 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'm not sure I understand what value basing on MediaStream provides in the
use cases of the MIDI API.  Aside from the existing gUM
security/permissions model, I mean.

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

A significant use case of the MIDI API is a software sequencer.  At the
height of my basement studio, I had approximately sixteen MIDI I/O devices
- that is, sixteen inputs plus sixteen outputs, with sixteen MIDI channels
each.  My sequencer had to be able to independently address these and keep
them organized - otherwise, every time I sat down at the computer and
opened up a project, I would have had to spend a significant chunk of time
selecting each device in the system UI.

It's a good idea to have a default device, but selection and retention need
to be supported.

-C