81–90 of 179 posts
Earlier quoted context omitted.
Use a square wave.
Ah yes, just run a square wave at twice the range of human hearing, then use a combination of filters to extract the desired ranges. Unfortunately you'd also need an infinite arrangement of filters.
Here's a synth using the technique:
>> Can the ridiculous overeagerness of Web Audio be reversed? Can we bring back a simple “play audio” API To be frank, graphics world had some type of standard (OpenGL) long time ago, next to DirectX. So WebGL had a good example. However in the audio world we haven't seen a cross platform quasi-standard spec covering Mac, Linux and Windows. So IMHO, non-web audio lacks also common standards for mixing, sound engineer…
I think the bigger issue is that non-experts sometimes get tasked with adding support for things.
The "audio device API that leaves the sample rate completely unspecified" example is, believe it or not, one I've seen before elsewhere. And yet, if you know the first thing about PCM samples, you know this is a mind-numbingly stupid mistake to make. Yet it's a mistake that a few people have made into shipping products, because they can't or won't reason about audio, and this did not stop them from being in charge of an audio API.
Mozilla had a competing api that just worked with sample buffers. Unfortunately it didn't win the standardization battle. https://wiki.mozilla.org/Audio_Data_API
It's a conspiracy theory, I know. Reality is probably far more boring and depressing. :/
Like the blog poster, I cut my teeth on the Mozilla API, and I was able to get passable sound out of a OPL3 emulator in a week's time. Perhaps Mozilla could convince other browser vendors to adopt their API in addition to Web Audio API?
Earlier quoted context omitted.
Ah yes, just run a square wave at twice the range of human hearing, then use a combination of filters to extract the desired ranges. Unfortunately you'd also need an infinite arrangement of filters.
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 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.
Isn't Web Audio based off of MacOS'x Audio API? I think the whole point is that Javascript used to be slow, and using the CPU as a DSP to process samples prevents acceleration. Seems to me what is needed is like "audio shaders" equivalent to compute/pixel shaders, that you farm off to OpenAL-like API which can be compiled to run on native HW. Even if you grant emscripten produces reasonable code, it's still bloated,…
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.)
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.…
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.
I worked on a (now abandoned) project a while back using Web Audio API, but it was NOT for Audio at all - in fact, it was to build a cross platform MIDI controller for a guitar effects controller. As someone mentioned elsewhere on this thread Android suffered from a crappy Audio/MIDI library. iOS's CoreMIDI was great, but not transportable outside of iOS/OSX. Web Audio API's MIDI control seemed a great way to go - ju…
I think I know what you mean, but in my mind, MIDI is very much Audio.
Oh, and we needed to use SYSEX a LOT in order to intercept clock timing messages, as well as complex data like preset names and multi parameter effect settings (EQ etc.). None of the messages sent/received affected music notes at all - it was all setting configuration only.
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.…
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 br…
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.