Re: Web MIDI polyfill

Dumping a bunch of responses together.

In short: Brian basically hit two points on the head:
1) The Web MIDI API is a low level API requiring capabilities or
permissions we do not currently have - namely, access to MIDI I/O devices.
 The interested parts of MIDI support, to me, are not about rendering
Standard MIDI Files to audio output (though I'm working on a project on
that in the background), it's about integrating support for MIDI
controllers (and synthesizers/output devices too).  There is a HUGE gap in
usability of synthesizers that require you to use a mouse or computer
keyboard vs. an 88-key weighted piano controller (or wind instrument
controller, guitar controller, etc.).  The live input/output part is the
interesting bit, not Standard MIDI files.

2) The whole point of this was to try out the API in practice, to guide
implementation and spec development.  I'd rather people NOT have to use it.
 :)

Marcos said:

>What's more concerning in the prollyfill is the way it's coded. I know Chris just slapped this together to get it working so I'm not going to criticize him on code quality.

Good, because it certainly is not great.  It was my first attempt at
writing a shim like that, and the only thing I can say is that it is
marginally usable.  As I said to you separately - I'm more than happy
to take pull requests, issue filings, whatever.  Point me in the right
direction.

>However, what we do see in his code is some things which are typical: not much respect for how the underlying WebIDL system works and resulting to CustomEvents to construct events… he even created his own DOM 2 based event dispatcher, which won't actually work if an element is assigned as a listener (because they can't participate in a DOM tree).

I'm glad (really!) that I'm making typical mistakes, because at least
my cursory attempt to figure out how to do this didn't turn up better
examples.  If you have a good code example of how to implement the
event system on an object that is not a DOM object, please point me at
it and I'll figure it out.  (Not sure I parsed your last statement -
who can't participate in a DOM tree, and why does that matter in this
instance?

> On Dec 13, 2012, at 3:32 AM, François REMY <francois.remy.dev@outlook.com <francois.remy.dev@outlook.com?Subject=Re%3A%20Web%20MIDI%20polyfill&In-Reply-To=%253CC06F32AA4E844847B468236004F31A0C%40marcosc.com%253E&References=%253CC06F32AA4E844847B468236004F31A0C%40marcosc.com%253E> (mailto:francois.remy.dev@outlook.com <francois.remy.dev@outlook.com?Subject=Re%3A%20Web%20MIDI%20polyfill&In-Reply-To=%253CC06F32AA4E844847B468236004F31A0C%40marcosc.com%253E&References=%253CC06F32AA4E844847B468236004F31A0C%40marcosc.com%253E>)> wrote:
> > Building on tops of browser plugins is a nice way to make prototypes but this is not a prolyfill in the sense that:

Perhaps I should have continued calling this library something else -
you'll note it's actually "shim" in the name.  But I'm not hung up on
naming - yes, in its current state this is absolutely a prototype, not
a production code library, and it likely needs a bunch of work to make
it so.  Happy to rename, tell me what I should call it.  Web MIDI API
Prototype Shim?

> > - it’s not immediate (the user will see a broken page the first time and will be asked to download a plugin)
> > - it’s not cross-platform (no plugin works on iOS and Windows Phone for example)
> > - it’s not forward compatible (the plugin may break, or not exist for newly popular platforms)

Indeed, those are all true.

> > I still believe we have to believe in our JavaScript-based prolyfill model, which is the only one that can truly be forward compatible. JavaScript is turing complete so there must be another way to support MIDI playback (for exemple converting the MIDI file into a MP3 on the go by transcripting the plugin using Emscripten).

As before: yup, you could convert a MIDI FILE into an MP3 on the fly -
that's what I was going to do with https://github.com/cwilso/SMFPlayer
eventually.  But that's a lot less interesting to me personally than
writing DJ software with real controllers.  :)  In short, the Web MIDI
API exposes hardware that you just don't get access to anywhere else
in the web platform today - so it requires a plugin at the moment.

-Chris




On Thu, Dec 13, 2012 at 8:31 AM, Brian Kardell <bkardell@gmail.com> wrote:

>
>
>
> On Thu, Dec 13, 2012 at 11:06 AM, Clint Hill <clint.hill@gmail.com> wrote:
>
>> I have to agree with François on this. I dislike the idea of a prollyfill
>> depending on a plugin. Flash was a very hard lesson (speaking from work
>> experience) for many devs and it was nearly ubiquitous. And don't we all
>> remember ActiveX? :)
>>
>>
>> On Dec 13, 2012, at 3:32 AM, François REMY <francois.remy.dev@outlook.com>
>> wrote:
>>
>>  Building on tops of browser plugins is a nice way to make prototypes
>> but this is not a prolyfill in the sense that:
>>
>> - it’s not immediate (the user will see a broken page the first time and
>> will be asked to download a plugin)
>> - it’s not cross-platform (no plugin works on iOS and Windows Phone for
>> example)
>> - it’s not forward compatible (the plugin may break, or not exist for
>> newly popular platforms)
>>
>> This is what the Flash experience reminds us: at some point Flash was
>> installed on 95% of the computers and using Flash to make prolyfills was
>> widely used (async file uploads, animations...). Now, Flash is not
>> available on most mobile platforms and the sites relying on Flash face
>> issues. This is not the kind of model we want to promote in next-web.
>>
>> I still believe we have to believe in our JavaScript-based prolyfill
>> model, which is the only one that can truly be forward compatible.
>> JavaScript is turing complete so there must be another way to support MIDI
>> playback (for exemple converting the MIDI file into a MP3 on the go by
>> transcripting the plugin using Emscripten).
>>
>> Nice achievement anyway ;-)
>> François
>>
>>
>>
>>
>> *De :* Brian Kardell
>> *Envoyé :* 13 décembre 2012 06:47
>> *À :* Innovimax W3C
>> *Cc :* public-nextweb@w3.org
>> *Objet :* Re: Web MIDI polyfill
>> On Wed, Dec 12, 2012 at 12:04 PM, Innovimax W3C <innovimax+w3c@gmail.com>
>>  wrote:
>>
>>
>>> Forwarded with permission from Chris Wilson
>>>
>>> FYI
>>>
>>> Mohamed
>>>
>>> ---------- Forwarded message ----------
>>> From: Chris Wilson <cwilso@google.com>
>>> Date: Tue, Dec 11, 2012 at 2:13 AM
>>> Subject: Web MIDI polyfill
>>> To: "public-audio@w3.org" <public-audio@w3.org>
>>>
>>>
>>> I just wanted to let the group know that I've now also updated my Web
>>> MIDI API polyfill (https://github.com/cwilso/WebMIDIAPIShim), which
>>> builds on top of the Jazz-soft.net NPAPI plugin to add Web MIDI API
>>> support on OSX and Windows (if you install the Jazz plugin v1.2 or later).
>>>
>>> The polyfill uses the current syntax of the API in the specification; I
>>> also added multiple simultaneous I/O support (the polyfill could previously
>>> only support one input and one output at a time), sending and receiving
>>> long messages (system exclusive), support for timestamps (on send and
>>> receive), albeit of course with only setTimeout-level precision (it is a
>>> JavaScript polyfill, after all), and (I think) proper event dispatching
>>> (i.e. you can use addEventListener as well as onmessage).
>>>
>>> In short - you should be able to include this polyfill in a project, and
>>> it will add Web MIDI support to your browser.  (Caveat: have not thoroughly
>>> tested the cross-browser implementation; I know CustomEvent is not there on
>>> IE<10, which would be an issue.)
>>>
>>> Happy to take further suggestions.
>>>
>>> -Chris
>>>
>>>
>>>
>>> --
>>> Innovimax SARL
>>> Consulting, Training & XML Development
>>> 9, impasse des Orteaux
>>> 75020 Paris
>>> Tel : +33 9 52 475787
>>> Fax : +33 1 4356 1746
>>> http://www.innovimax.fr
>>> RCS Paris 488.018.631
>>> SARL au capital de 10.000 €
>>>
>>
>>
>> Aside from the fact that this uses a plugin this is an excellent example
>> of what I had in mind IMO.  After looking at it though and talking to some
>> people -- I don't think that it uses a plugin really makes it problematic
>> as a prollyfill or anything, so maybe I was thinking too narrow
>> originally... I mean, adopting that strategy actually makes it more
>> practical to fill a whole lot more things.
>>
>> Thoughts?
>>
>>
>> --
>> Brian Kardell :: @briankardell :: hitchjs.com
>>
>>
>>
>
> OK, leaving aside the ecmascripten idea for a minute... Let me explain why
> I eventually changed my mind on this "in general" and not specifically
> related to whether or not this particular one should or shouldn't be (I
> think that is a somewhat separate question): What is the purpose of a
> prollyfill? In my mind, it serves many purposes - but the primary one is
> that it allows us to have an implementation along with a draft proposal
> which both helps flesh out the proposal and actually lets people try to use
> the APIs, maybe even fork and compete - so that early on we can easily
> iterate and things aren't likely to break if we need to change the API
> because the author opts in.  A huge benefit to this is that it means that
> many of these can be used _practically_ not just experimentally and get a
> whole more eyeballs and users as they get popular.
>
> However - there is a known problem that a great many things are simply
> unprollyfillable - this may actually be one or not - leave that aside for a
> moment - because it is a low level API requiring capabilities or
> permissions we do not currently have.  Losing the ability to prollyfill in
> that area is, to my mind, a _very great_ loss.
>
> Now, what are the implications?  The implications are that it doesn't work
> on certain kinds of browsers and not without permission of the viewer.
>  Actually - that's a lot like the prefixed "mavens" model we have now -
> it's not cut to the whole world, but just a segment of willing people who
> want to test/play/improve/etc... If I step back and look at it honestly -
> it seems better than the prefixing model that we currently have IMO because
> you fill at least of great swath of them at once and it's not tied to a
> single browser, should be relatively forward compatible...  An ideal case
> might be that things at that level start out that way and serve as
> proof/fire to get those low level APIs in there -- that would free up the
> work hours of all of the implementers to do things we really need them to
> do with great efficiency, focus and speed :)
>
> As I said at the outset - one thing that is inevitably going to be
> necessary for us is some sort of compatibility chart like you see on
> caniuse or something... It seems to me that as long as they are clearly
> flagged that way - this could actually work pretty well.
>
> Another thing I think we would want realize is that we want to encourage
> competition and review... Francois came up with an interesting idea - I
> think if we could see it and it was performant enough, not a trillion lines
> of code and required no plugins - that is clearly what I'd endorse... you
> know?  And honestly, Chris Wilson might too because who wants to rely on a
> plugin if  you don't have to.
>
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>
>