Kinda tagential to the thread, but what's the best book for an introduction to audio programming for an experienced, language agnostic coder (java, c, c++, obj-c, etc)?
Fantastic resource here:
I don’t know who the Web Audio API is designed for
141–150 of 179 posts
Re: I don’t know who the Web Audio API is designed for
#142I 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.…
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.
Re: I don’t know who the Web Audio API is designed for
#143The Web Audio API is designed for web developers who would want to integrate sound into their web apps. Notifications, etc. That pre-browser era where we would have sounds for everything. Minimize window, user logged in, logged out, all that crap. Also the API has good support for visual. Spectrum analysis. This is pretty good for an education course to offer for beginners on sound processing. I wouldn't use it for a…
This explanation doesn't fit, because already solved all the scenarios you're describing. Web Audio attempts to solve other problems, and does a bad job of it.
Yes, Audio does work. But the Web Audio API has some things more to offer for the simpler stuff. Simple games, timing, effects, detune, etc.
Re: I don’t know who the Web Audio API is designed for
#144Earlier quoted context omitted.
But Chrome for Android didn't come out until 2012 and Chris Rogers started the Web Audio work in 2009. I think someone would have had to have been exceptionally farsighted to think "Android's audio stack is going to suck for several years so we need to design around that now".
At that point in time, though, you could be forgiven with "Sheesh. Javascript is so painfully slow that nobody will ever pass PCM samples around in it." So, at every point in time up to and including now, you've always got something resisting low-latency PCM. Android is just the latest reason. Side note: it looks like Chris Rogers bowed out of Web Audio about 2012/2013 timeframe.
You couldn't really, since AudioData worked pretty well.
Also, it was obvious JS perf would get better and better.
Re: I don’t know who the Web Audio API is designed for
#145I'm running a SaaS built on the back of the Web Audio + WebRTC apis. While it isn't perfect at all, it is still pretty impressive what progress has been made in the last few years allowing you to do all kinds of audio synthesis and processing right in the browser. It seems to me that it is a pretty general purpose api in intent. The approach seems to be to do the easy low hanging fruit first and then get to the more complicated things. This doesn't satisfy any single use case quickly but progress is steady. No doubt it would be nice if it was totally capable out of the gate but I'm simply happy that even the existing capabilities are there. Be patient, it will improve vastly over time.
EDIT: I should also add that the teams behind the apis are quite responsive. You can make an impact in the direction of development simply by making your needs/desires known.
Re: I don’t know who the Web Audio API is designed for
#146I disagree with a lot of the assertions in this blog. You have to suspend some of your expectations since this is all .js. you can't have a js loop feeding single samples to a buffer. Js isn't deterministic to that level of granularity, but overall it's fast enough to generate procedural audio in chunks if you manage the timing. If you check out some of the three.js 3d audio demos you can see some pretty cool stuff b…
> Js isn't deterministic to that level of granularity
Why not? I linked a test app [0] in my post that generates generate PCM data on demand, and fast. It works deterministically on all the browsers. Mozilla certainly implemented AudioData back in 2011 and it was fast enough for them.
> He'll I wrote a tron game and did the audio using audio node chains and managed to get something really close to the real tron cycle sounds, without resorting to sample level tweaking
Why couldn't this be a high-level userspace library like three.js? Yes, with a lot of creative energy, you can recreate a lot of sounds, I'm willing to believe that. But I think a low-level API would have been more useful from the getgo.
Re: I don’t know who the Web Audio API is designed for
#147Here's my take on the history here: http://robert.ocallahan.org/2017/09/some-opinions-on-history... From the beginning it was obvious that JS sample processing was important, and I tried hard in the WG to make the Web Audio API to focus on that, but I failed.
Back there I followed a bit the discussion and your alternative spec, which was really interesting. If I remember it well, that will take lots of work and you were the only one working to get it implemented on FF. Are there any plans to get back to that? Maybe as an independent API for JS sample processing by workers only, in parallel with WA? Congratulations on your past efforts and thanks in advance for your answers.
Re: I don’t know who the Web Audio API is designed for
#148Web audio can be used with this: https://wavesurfer-js.org/
I'm not making the connection between the link and the point you're trying to make. Can you elaborate?
I was expressing my excitement over something neat which implicitly answers the query in the title that it was designed for me. People who think wave analysis is neat. There are at least 3 other posts on here describing the basic features of wave analysis are just fine. Thanks for the down votes!
Re: I don’t know who the Web Audio API is designed for
#149>you can’t directly draw DOM elements to a canvas without awkwardly porting it to an SVG
This is not a wart, this is a security feature. Of course, it wouldn't be a necessary limitation if the web wasn't so complicated, but the web is complicated.
Re: I don’t know who the Web Audio API is designed for
#150Earlier quoted context omitted.
You're making music. It's not that difficult. http://kruhft.bandcamp.com/ Here's a synth using the technique: http://busfactor1.ca/kruhft
I propose a challenge then. I'll give you an arbitrary stream in the format of a .wav, and you send me code, in JavaScript, that uses an series of infinite OscillatorNodes that reproduces that stream completely accurately. I won't even make you write the code that generates the stream, I'll just require that one sample. If you can do it, I'll give you $1000 out of my own pocket.
If you're not sampling at an infinite sample rate, you don't need an infinite series of nodes.
Given Nyquist, a non-infinite series of [non-trivial power of 2] nodes will do the job just fine.
Audio FFT/iFFT processing typically uses 512 or 1024 bins, although sometimes you can get away with fewer.
In practice, iFFT doesn't use discrete oscillators for resynthesis, because the whole point of iFFTs is to limit the amount of work you have to do.
But there's no reason in theory a limited number of oscillators couldn't do the job. (I've done resynthesis like this in SuperCollider when I wanted special effects that FFTs can't produce.)
I doubt WA would be fast enough on most machines, but it would probably be possible - if rather dumb - on powerful hardware.