BloopdeeBloop
Ever since I set foot in the valley, I’ve been going to plenty of hackathons, but not exactly getting much done. I’ve noticed myself spending much more time talking and, may I say, socializing (gasp!), rather than hacking. Highly unusual, if I say so myself. However, during the fairly recent World Series of Hack put on by Mozilla, I forced myself to sit down and do code. And what came out was Bloopdeebloop.
Hackathon Thoughts
First, a word about the World Series of Hack (WSOH) hackathon: it was one of the most highly organized hackathons I have ever been to, with a corresponding number of constraints. Not that I have been to many hackathons, probably less than 10. However, not a single other hackathon has “strongly encouraged” people signing up to explicitly say what they were going to hack on before getting to the hackathon. Though, there were good things that came out of the amount of organization: for instance, the food was not your usual pizza, and the venue was nice (possibly too nice: hackers don’t care about the decor when they’re deep in a code session).
Genesis
Despite the encouragement to know what I was going to work on before I got there, and even an allowance to begin a week early, I came into the hackathon with only a vague idea of what I was going to work on. I was possibly thinking about doing a next-generation Hacker Mapper, but that died an hour in when I discovered that doing monocular visual SLAM was actually not that easy to pick up and do, especially when one was already sleep deprived at the beginning of a hackathon.
Not wanting the night to go to waste, I perused the WIP hack list again, and found an interesting project I somehow overlooked on the first 10 look throughs: a Reactables clone with javascript and the Mozilla audio APIs. If you talk to me about tech, you’ll find that I think that social is kind of overblown. Audio, though, I can get behind: as a musician who is unwillingly giving up his tools and what little competence he has, if I can tie together an offshoot of the main thread of my life (computers) and music, why, that’s a winning combination.
So I found the guy, and we got down to hacking.
About
The hack itself used processing.js (a javascript clone of the processing language) and, as mentioned before, the Mozilla audio APIs (making the HTML5 audio APIs not suck so badly in terms of features). We split it up along the natural fault line, with myself doing the graphical interface with processing and him interfacing with the audio backend. I hadn’t programmed in processing before, so that was… interesting. Looking at it from the point of view of a layman, it makes sense why they structured the language that way (since it is structured for the non-hacker), but as a programmer it felt weird and kind of awkward. Perhaps it would be an acquired taste…
Overall, we spent the bulk of the time building the actual engine itself ie. getting blips and bleeps coming out of the speakers (and competing with the looping dance-heavy soundtrack piping into the room) and circles and arcs drawn to the screen (competing with the black lights), as well as mashing the two together (competing with all the other hacks). There’s really not too much to say on the matter: it’s all pretty well-traversed ground.
What’s interesting is the stuff we didn’t get around to, which would’ve used more of the HTML5 stuff the hackathon was pushing: stuff like persistence (with local storage) or collaboration (with websockets or now.js). Also, getting actual music instead of random bloops and bleeps out of the app would have been cool.
Download/Demo
So you want to actually hear these bloops and bleeps? Well, wait no longer, for you can follow this link:
And hear it! Well, if you’re using Firefox 5-7. Remember, this is using the Mozilla audio API, and as of now no one else has implemented the extended API.
Wait, you want the source, you say?
And, well, that’s all folks!