[web-audio-api] Questioning the current direction of the Web Audio API (#263)

So ... where to start?

First, short introduction, as probably nobody knows me here. My name is Sebastien Piquemal, I am a web developer and a musician. I've been studying (and playing/composing) computer music for a few years. Which means that I am a heavy [SuperCollider](http://supercollider.sourceforge.net/) and [Pure Data](http://puredata.info/) user (those are the 2 most used languages for audio programming).
I am also the maintainer of the [WebPd](https://github.com/sebpiq/WebPd) library (Pure Data in JavaScript) and more recently I started to write a [node.js](https://github.com/sebpiq/node-web-audio-api) implementation of Web Audio API.
This message is kind of a rant, as I have been increasingly frustrated with trying to use Web Audio API for doing musical experiments. I am sorry about that, I hope nobody will feel personally attacked.

The previous version of WebPd (written about 2 years ago), used only custom dsp. So last spring, I thought "why not using as much of web audio as possible, to get a better performance" ? So I started trying to map Pure Data objects to Web Audio API objects (as both Pd and WAA are dataflow, so they use a very similar paradigm). It turned out to be pretty much impossible. For a simple reason is that Web Audio API really lacks objects, so I would have to implement most of them using **ScriptProcessorNodes**, and then loose all the benefits of using Web Audio API (all dsp in one ScriptProcessorNode would be faster).

As a matter of fact, there is a few good libraries out there, all written post-web audio API (I won't mention other good libraries written before WAA) for audio programming in JavaScript :

https://github.com/colinbdclark/flocking
https://github.com/charlieroberts/Gibber
https://ccrma.stanford.edu/~mborins/420b/#/3  

Funny fact is that all of them use the ScriptProcessorNode.
The only stab - that I know of - at implementing some serious sound programming library on top of other WAA nodes is [waax](https://github.com/hoch/waax). But it cruelly lacks objects, and uses a couple of [ugly hacks](https://github.com/hoch/WAAX/blob/master/src/units/generators/Noise.js#L14).

In my opinion web audio API is very deceiving, and a lot of people seem to think that they can implement anything they have on a desktop with the existing nodes **not using ScriptProcessorNode, which is tagged as evil**.
In fact, the draft identifies use cases which basically covers most audio applications (audio production and composition, artistic audio exploration, games ...).
However ... artistic exploration, no way. Audio production ... certainly not for realtime applications. For example, no way you could implement something eve close to Ableton Live. Games, yeah ... you could do some old fashioned "load your sound assets, and apply a couple of filters to them", but no way you could do some generative audio using some more advanced synthesis techniques. You probably even couldn't implement something like FMOD, unless you pre-render most of the assets.

I love the idea of Web Audio API. But right now I feel that it really lacks prespective, and a clear direction.
I'd really like to hear people's opinion about why they do it like that, how and why they think it can/will be used for real-life applications, because the goals stated in the draft are - in my humble opinion - completely unrealistic with the current functionalities.

I am sorry to be a bit harsh, and question this project in its foundations, but I suppose that's what you get for being implied in open standards : any random angry guy out there can come and complain :)

---
Reply to this email directly or view it on GitHub:
https://github.com/WebAudio/web-audio-api/issues/263