Re: Aiding early implementations of the web audio API

Hi Chris,

On 2012-05-22, at 2:47 PM, Chris Wilson wrote:
> What level do you believe we should be codifying, then?  Because if I take that approach to its logical conclusion, I really do end up thinking you're looking for something that only defines the input and output streams, and the developer is on their own for everything in between.  That's certainly simple enough.  I don't think we're going to see a lot of audio apps being built if that's all the support they get, though.  And there's nothing preventing those apps from being built today, then - with the AudioData API, e.g. - and from the appropriate support libraries being built.  But they're not.

Precedence out on the web suggests that this isn't true at all. There are no lack of excellent and well-adopted libraries built on top of, say, Canvas or WebGL. The browsers provide a performant low-level implementation, and library developers flourish and innovate. Here are some random examples:

http://mrdoob.github.com/three.js/
http://d3js.org/
http://processingjs.org/

Not to mention the world's most famous JavaScript toolkit, jQuery, which took a very unique approach to providing an alternative to the DOM. We all know it now has massive adoption and general developer adoration. I don't see any reason why audio on the web can't be the same way. We know some audio processing algorithms won't be performant on the JavaScript side, but there is no reason we can't provide fast native primitives and a simple, solid foundational API for end users and libraries alike.

>>  This approach allows for the "cows to pave the path", so that the web platform isn't overspecified with APIs that nobody wants to use (I'm not saying nobody wants to use Web Audio API, heh, however I think it would be better off as a JS library).
> 
> I'm generally in favor of paving cow paths where they exist.  I'm not as pleased with turning a bunch of cows out into the forest and seeing what they come up with as a design methodology, though. 

We've seen that in practice on the web, it is the JavaScript libraries (such as jQuery), not W3C specifications (such as the DOM), that provide the best APIs due to healthy innovation and competition amongst libraries.

Colin

Received on Tuesday, 22 May 2012 20:00:10 UTC