[fenomas]

I have to cast a vote in opposition here.

I've been heavily into procedural audio for a year or two, and have had no big issues with using Web Audio. There are solid libraries that abstract it away (Tone.js and Tuna, e.g.), and since I outgrew them working directly with audio nodes and params has been fine too.

The big caveat is, when I first started I set myself the rule that I would not use script processor nodes. Obviously it would be nice to do everything manually, but for all the reasons in the article they're not good enough, so I set them aside, and everything's been smooth since.

So I feel like the answer to the articles headline is, today as of this moment the Web Audio API is made for anyone who doesn't need script nodes. If you can live within that constraint it'll suit you fine; if not it won't.

(Hopefully audio worklets will change this and it'll be for everyone, but I haven't followed them and don't know how they're shaping up.)

[kevingadd]

The problem is not that Web Audio doesn't do useful things. The problem is that it's a terrible foundation to build applications on top of, because it only solves a tiny set of use cases. This results in way too many people needing script nodes.

Other proposals for audio APIs solved a wider set of use cases, while also making it possible to do procedural audio without depending on browser vendors to implement key features for you.

[p0nce]

For music software you would need script nodes right away. There isn't one single way to implement filters, compressors, etc. Perhaps that's not the focus of the API.

[Jasper_]

If you're a creative mind and you constrain yourselves to the effects available in Web Audio, I'm sure you'll be just at home.

The effects are useful in one setting: hobbyist and toy usage, where you really don't have that many constraints and can play with whatever cool things are around. That said, I'm sure you'd actually get a lot more mileage out of a library of user-made script nodes, rather than whatever the browsers have built for you.

If you're trying to build something production-ready, or port an existing system to the web, most of the fun toys seem like just that: toys.

AudioWorklets don't look like they would improve things for me, but that's a topic for another blog post.

[fenomas]

I didn't say I was making trivial toy that isn't production ready. :| I just said I'm not using script nodes, and I think that's what TFA boils down to - half of it is about script nodes not being usable and the other half is about sample buffers not being suitable replacements for script nodes.

And obviously not having raw script access isn't a good thing. Nonetheless, the other nodes mostly work as advertised, in my limited experience so far, so the stuff that you'd expect to be able to do with them (e.g. FM/AM synthesis) seems to work pretty well.

> AudioWorklets don't look like they would improve things for me, but that's a topic for another blog post.

AFAIK worklets are supposed to be script processor nodes that work performantly. They wouldn't solve the sample rate problems mentioned in TFA but apart from that I'd think they should be pretty usable if they someday work as advertised.

[bigbadotis]

Agreed that you can do much more than "trivial toys" with the current WAAPI! But you can only do a small part of FM without feedback (unless you're just talking about vibrato as opposed to canonical FM synthesis). Look at the modulation paths (aka algorithms) of original Yamaha FM synths...