4 ms·

My biggest gripe with Firefox is that it doesn't support MIDIAccess. So any web app that works with an electronic piano, doesn't work. They've been saying they

My biggest gripe with Firefox is that it doesn't support MIDIAccess. So any web app that works with an electronic piano, doesn't work. They've been saying they are working on it for years. Works in Chrome, Brave, Opera, Edge, etc. https://developer.mozilla.org/en-US/docs/Web/API/MIDIAccess https://developer.mozilla.org/en-US/docs/Web/API/MIDIAccess https://bugzilla.mozilla.org/show_bug.cgi?id=836897 https://bugzilla.mozilla.org/show_bug.cgi?id=836897 It's actually pretty bizarre since the basic functionality (hit a note on the piano, send it to the web page that is listening for such events) is so trivial, compared to the vast majority of features.

robin_reala 7y ago
The source you linked to has the spec created by a Google engineer and in working draft. All the browsers you mention are based on Chromium so will automatically inherit this functionality. I’m not saying it’s not something useful to implement, but it usually takes some time and a stable specification before other browse manufacturers want to implement non-mainstream functionality.
- robbrown451 7y ago
  Yes well it's been in working draft for about 7 years, and I'm pretty sure the holdup on finalizing the draft is on the Mozilla side. https://github.com/mozilla/standards-positions/issues/58 https://github.com/mozilla/standards-positions/issues/58
  - boomlinde 7y ago
    Reminds me of the audio API mess. If you want to stream arbitrary sample data to an output you can either use ScriptProcessorNode (simple API, well supported but deprecated) or AudioWorkletNode (over-engineered API, largely unsupported and experimental). The stall in that case seems caused by the overly ambitious design of the Web Audio API altogether. It's utterly useless for audio processing or synthesis except when using the aforementioned APIs because it mandates a bunch of underspecified high level concepts. Just let me fill a buffer with floats for the speakers and read a buffer of floats for the mic. That's literally all I need, and literally the only way you can build, say, a compressor and have full control of its characteristics. When researching the best option I found this, so I'm not alone in thinking this: https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-audio-api-is-designed-for/ https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-aud...
dan-robertson 7y ago
I guess the reason is probably that it probably requires a developer with a midi device, and it affects too few users for Mozilla to want to prioritise it. The bug currently has priority P3. There are about 8300 existing P1 and P2 bugs, and over 10000 P3 bugs. Saying that it works in chrome, brave, opera, edge etc sounds like “look at all these other vendors who put the effort in” but really they are all running the same code these days so you could instead write “chromium implements it”.
- boomlinde 7y ago
  > I guess the reason is probably that it probably requires a developer with a midi device That is not true at this point. AFAIK Windows, OS X and ALSA all support virtual MIDI devices. Windows and OS X (last time I used it) ship with virtual General MIDI outputs and there is a lot of free third party software for virtual input. I'd rather say that the reason is probably that you need a developer with domain knowledge and interest, and a consensus on what the standard should include.
xen2xen1 7y ago
Your biggest problem is that it doesn't work with a MIDI keyboard? Ok? I have to ask why this is so important? What is the use case here?
- robbrown451 7y ago
  Browsers are essentially operating systems, and can allow replacing desktop apps with web apps. I mean, I don't use a stylus, but if I did a lot of graphics stuff and liked using a stylus, but I couldn't use a stylus within one brand of browser, suddenly the browser is far less useful to me. Same goes for other things. WebGl is very rarely useful for me. But if I liked playing (or developing) games, it would be awesome if the browser allowed that sort of thing rather than forcing developers to build for a specific native platform. So an immense amount of work has gone into webGl, even though it appeals to a fairly small subset of users right now. I'd guess you could imagine desktop apps that use a midi keyboard. Like, ones to learn piano, or otherwise do interesting musical stuff. I mean, they have WebAudio, but its usefulness is limited if they can't do anything with a keyboard. In my case, I develop a web app that does music stuff. (and it actually has to be a web app because of the way it uses YouTube) It's disappointing that I have to say "Chrome/Blink only." https://www.youtube.com/watch?v=rytYcOUZH30 https://www.youtube.com/watch?v=rytYcOUZH30

robin_reala 7y ago

The source you linked to has the spec created by a Google engineer and in working draft. All the browsers you mention are based on Chromium so will automatically inherit this functionality. I’m not saying it’s not something useful to implement, but it usually takes some time and a stable specification before other browse manufacturers want to implement non-mainstream functionality.

robbrown451 7y ago
Yes well it's been in working draft for about 7 years, and I'm pretty sure the holdup on finalizing the draft is on the Mozilla side. https://github.com/mozilla/standards-positions/issues/58 https://github.com/mozilla/standards-positions/issues/58
- boomlinde 7y ago
  Reminds me of the audio API mess. If you want to stream arbitrary sample data to an output you can either use ScriptProcessorNode (simple API, well supported but deprecated) or AudioWorkletNode (over-engineered API, largely unsupported and experimental). The stall in that case seems caused by the overly ambitious design of the Web Audio API altogether. It's utterly useless for audio processing or synthesis except when using the aforementioned APIs because it mandates a bunch of underspecified high level concepts. Just let me fill a buffer with floats for the speakers and read a buffer of floats for the mic. That's literally all I need, and literally the only way you can build, say, a compressor and have full control of its characteristics. When researching the best option I found this, so I'm not alone in thinking this: https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-audio-api-is-designed-for/ https://blog.mecheye.net/2017/09/i-dont-know-who-the-web-aud...

dan-robertson 7y ago

I guess the reason is probably that it probably requires a developer with a midi device, and it affects too few users for Mozilla to want to prioritise it. The bug currently has priority P3. There are about 8300 existing P1 and P2 bugs, and over 10000 P3 bugs. Saying that it works in chrome, brave, opera, edge etc sounds like “look at all these other vendors who put the effort in” but really they are all running the same code these days so you could instead write “chromium implements it”.

boomlinde 7y ago
> I guess the reason is probably that it probably requires a developer with a midi device That is not true at this point. AFAIK Windows, OS X and ALSA all support virtual MIDI devices. Windows and OS X (last time I used it) ship with virtual General MIDI outputs and there is a lot of free third party software for virtual input. I'd rather say that the reason is probably that you need a developer with domain knowledge and interest, and a consensus on what the standard should include.

xen2xen1 7y ago

Your biggest problem is that it doesn't work with a MIDI keyboard? Ok? I have to ask why this is so important? What is the use case here?

robbrown451 7y ago
Browsers are essentially operating systems, and can allow replacing desktop apps with web apps. I mean, I don't use a stylus, but if I did a lot of graphics stuff and liked using a stylus, but I couldn't use a stylus within one brand of browser, suddenly the browser is far less useful to me. Same goes for other things. WebGl is very rarely useful for me. But if I liked playing (or developing) games, it would be awesome if the browser allowed that sort of thing rather than forcing developers to build for a specific native platform. So an immense amount of work has gone into webGl, even though it appeals to a fairly small subset of users right now. I'd guess you could imagine desktop apps that use a midi keyboard. Like, ones to learn piano, or otherwise do interesting musical stuff. I mean, they have WebAudio, but its usefulness is limited if they can't do anything with a keyboard. In my case, I develop a web app that does music stuff. (and it actually has to be a web app because of the way it uses YouTube) It's disappointing that I have to say "Chrome/Blink only." https://www.youtube.com/watch?v=rytYcOUZH30 https://www.youtube.com/watch?v=rytYcOUZH30