For people who have shipped non-trivial Web Audio projects — what was the hardest part of debugging your audio graph?
Cool app! Would you mind sharing what you used for the node interface? I am deliberating between Rete and React Flow for a project.
Great stuff. Web Audio API designers were a tad too imaginative for their own good.
Any chance for an AudioWorkletNode example?
Thanks!
AudioWorkletNode support is on the roadmap, along with proper multichannel (merger/splitter) visualization. I'm prioritizing core graph stability first, then expanding node coverage.
If you're interested, you can subscribe for updates at the bottom of the landing page. I'll share progress there.
I'm not familiar with the Web Audio API, but I am interested in audio APIs in general. Could you explain where the designers went wrong? The templates listed in this (very nice!) app seem to look relatively sane as these things go.
IIRC back in the day it was criticized for having unnecessary abstractions and limitations that were seemingly arbitrary.
For instance, you can't restart an oscillator node. Once you call stop it's the end. A node that's stopped is also immediately disconnected.
ScriptProcessorNode, broadly speaking, sucked, because it was running in the main thread:
https://developer.mozilla.org/en-US/docs/Web/API/ScriptProce...
so eventually it was replaced with AudioWorkletNode combined with AudioWorkletProcessor:
https://developer.mozilla.org/en-US/docs/Web/API/AudioWorkle...
https://developer.mozilla.org/en-US/docs/Web/API/AudioWorkle...
Arguably people would have been happy having just these two from the get go.
Compare this to an API that was already mainstream back when Web Audio API was first developed:
https://steinbergmedia.github.io/vst3_dev_portal/pages/Techn...
https://news.ycombinator.com/item?id=47216773 21923#368-705