Re: Web MIDI polyfill

Hi Chris! Welcome to our little hideout :)  


On Thursday, December 13, 2012 at 9:52 PM, Chris Wilson wrote:

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

Exactly :)  
  
> 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.

So, here is my rewrite of how I think it should work (not done, but working nicely in Chrome):
https://github.com/marcoscaceres/WebMIDIAPIShim/blob/gh-pages/WebMIDIAPI.js

(note that I've changed the API a bit … now I need to sell you and the Web Audio WG on the changes :) )

It still needs some further integration with WebIDL's error handling. The only guidance I could give you is to try to follow the WebIDL spec (yes, WebIDL is fairly illegible … we need to fix that as a larger community).   

I'll also recommend exposing the interfaces through Object.defineProperties.   
  
> > 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?

The way I've been doing it is to create a fake element:

var dispatcher = document.createElement('x-eventDispatcher');  

then I wrap:  
dispatcher.addEventListener(…)
dispatcher.removeEventListener(…)
dispatcher.dispatchEvent(…)

It then handles everything for me.  

You are correct that in this instance it does not matter about the DOM Tree. See the link above to see it in action.   
  
> > On Dec 13, 2012, at 3:32 AM, François REMY <francois.remy.dev@outlook.com (mailto: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 (mailto: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.


This is going to be sooooo awesome if it gets implemented in browsers :)  

Kind regards,
Marcos

Received on Friday, 14 December 2012 17:06:46 UTC