Generation of Music Using Pure JS and HTML5

This is really neat! I wonder if this would be a smaller file/render size to implement over a normal audio file for HTML5 games. If so, I'm sure with a bit of work, you could make a cool "8 bit sounding" theme song for your game!

This rules. The other weekend I was feeling curious and started a little project to see what it takes to get up and running doing basic audio synthesis: https://github.com/nicolasmiller/bleeper. I got distracted with some other stuff, but the goal is to compile examples in as many languages/environments as possible.

I looked at the JS over here http://codebase.es/riffwave/riffwave.js and find this line

     this.dataURI = 'data:audio/wav;base64,'+FastBase64.Encode(this.wav);

(edit... more accurately the whole RIFFWAVE function blows my mind)

Really quite revolutionary (in terms of my understanding)... I already knew about making JPEGS etc, so this makes perfect sense but just seeing him build all the headers for a wav file in memory then "spit it out" to the page is stunning.

Kudos, Bravo, Standing slow clap, etc...

Thanks for sharing.

web audio api also does help.. for instance https://github.com/dashersw/pedalboard.js

The problem is that this lets you generate a buffer, and when you're done with that, play it back, but it doesn't let you push blocks of audio continually while previous blocks play. That will be necessary for any real-time audio application like NES emulation. Ultimately, this should be solved with the Web Audio API, but so far that appears to implemented in Firefox/Chrome/Safari, and only partly in those. I can see a Flash shim being useful there.

Now, in the mean time, I do have an idea of how this might be implemented on top of Riffwave.js, but it's iffy. The problem is that while the HTML5 audio element does have some events that tell you about playback status, we cannot possibly rely on JS events (or the placement of new audio tags) to give us the temporal granularity needed for audio timing. If you mistime the beginning of one block from the end of the previous block by half a millisecond, you'll hear an audible pop.

So one possible solution would be to crossfade blocks, using an overlap period on the same order as your timing uncertainty. In the cleverest implementation, the timing uncertainty would be continually measured and the overlap size would be adapted to be as low as possible.

But that's not a perfect solution. It would ameliorate the problem, but it would also introduce its own artifacts. For example, if you have a 440 Hz sine wave playing, and one block is offset by the next by 1.13 ms, then at the midpoint between two blocks (where each block is at 50% volume), the waves will interfere completely, resulting in a point of silence. The artifact would be soft, but it would still be a problem.