Posts Tagged musichackday
How the Bonhamizer works
Posted by Paul in code, fun, The Echo Nest on February 21, 2013
I spent this weekend at Music Hack Day San Franciso. Music Hack Day is an event where people who are passionate about music and technology get together to build cool, music-related stuff. This San Francisco event was the 30th Music Hack Day with around 200 hackers in attendance. Many cool hacks were built. Check out this Projects page on Hacker League for the full list.
My weekend hack is called The Bonhamizer. It takes just about any song and re-renders it as if John Bonham was playing the drums on the track. For many tracks it works really well (and others not so much). I thought I’d give a bit more detail on how the hack works.
Data Sources
For starters, I needed some good clean recordings of John Bonham playing the drums. Luckily, there’s
set of 23 drum out takes from the “In through the out door” recording session. For instance, there’s
this awesome recording of the drums for “All of my Love”. Not only do you get the sound of Bonhmam
pounding the crap out of the drums, you can hear him grunting and groaning. Super stuff. This particular
recording would become the ‘Hammer of the Gods’ in the Bonhamizer.
From this set of audio, I picked four really solid drum patterns for use in the Bonhamizer.
Of course you can’t just play the drum recording and any arbitrary song recording at the same time and expect the drums to align with the music. To make the drums play well with any song a number of things need to be done (1) Align the tempos of the recordings, (2) Align the beats of the recordings, (3) Play the drums at the right times to enhance the impact of the drums.
To guide this process I used the Echo Nest Analyzer to analyze the song being Bonhamized as well as the Bonham beats. The analyzer provides a detailed map for the beat structure and timing for the song and the beats. In particular, the analyzer provides a detailed map of where each beat starts and stops, the loudness of the audio at each beat, and a measure of the confidence of the beat (which can be interpreted as how likely the logical beat represents a real physical beat in the song).
Aligning the tempos (We don’t need no stinkin’ time stretcher)
Perhaps the biggest challenge of implementing the Bonhamizer is to align the tempo of the song and the Bonham beats. The tempo of the ‘Hammer of the Gods’ Bonham beat is 93 beats per minute. If fun.’s Some Nights is at 107 beats per minute we have to either speed Bonham up or slow fun. down to get the tempos to match.
Since the application is written in Javascript and intended to run entirely in the browser, I don’t have access to server side time stretching/shifting libraries like SoundTouch or Dirac. Any time shifting needs to be done in Javascript. Writing a real-time (or even an ahead-of-time) time-shifter in Javascript is beyond what I could do in a 24 coding session. But with the help of the Echo Nest beat data and the Web Audio API there’s a really hacky (but neat) way to adjust song tempos without too many audio artifacts.
The Echo Nest analysis data includes the complete beat timing info. I know where every beat starts and how long it is. With the Web Audio API I can play any snippet of audio from an MP3, with millisecond timing accuracy. Using this data I can speed a song up by playing a song beat-by-beat, but adjusting the starting time and duration of each beat to correspond to the desired tempo. If I want to speed up the Bonham beats by a dozen beats per minute, I just play each beat about 200 ms shorter than it should be. Likewise, if I need to slow down a song, I can just let each beat play for longer than it should before the next beat plays. Yes, this can lead to horrible audio artifacts, but many of the sins of this hacky tempo adjust will be covered up by those big fat drum hits that will be landing on top of them.
I first used this hacky tempo adjustment in the Girl Talk in a Box hack. Here’s a few examples of songs with large tempo adjustments. In this example, AWOLNation’s SAIL is sped up by 25% you can hear the shortened beats.
And in this example with Sail slowed down by 25% you can hear double strikes for each beat.
I use this hacky tempo adjust to align the tempo of the song and the Bonham beats, but since I imagine that if a band had John Bonham playing the drums they would be driven to play a little faster, so I make sure that I speed on the song a little bit when I can.
Speeding up the drum beats by playing each drum beat a bit shorter than it is supposed to play gives pretty good audio results. However, using the technique to slow beats down can get a bit touchy. If a beat is played for too long, we will leak into the next beat. Audibly this sounds like a drummer’s flam. For the Bonhamizer this weakness is really an advantage. Here’s an example track with the Bonham beats slowed down enough so that you can easily hear the flam.
When to play (and not play) the drums
If the Bonhamizer overlaid every track with Bonham drums from start to finish, it would not be a very good sounding app. Songs have loud parts and soft parts, they have breaks and drops, they have dramatic tempo changes. It is important for the Bonhamizer to adapt to the song. It is much more dramatic for drums to refrain from striking during the quiet a capella solos and then landing like the Hammer of the Gods when the full band comes in as in this fun. track.
There are a couple of pieces of data from the Echo Nest analysis that I can use to help decide when to the drums should play. First, there’s detailed loudness info. For each beat in the song I retrieve information on how loud the beat is. I can use this info to find the loud and the quiet parts of the song and react accordingly. The second piece of information is the beat confidence. Each beat is tagged with a confidence level by the Echo Nest analyzer. This is an indication of how sure the analyzer is that a beat really happened there. If a song has a very strong and steady beat, most of the beat confidences will be high. If a song is frequently changing tempo, or has weak beat onsets then many of the beat confidence levels will be low, especially during the tempo transition periods. We can use both the loudness and the confidence levels to help us decide when the drums should play.
For example, here’s a plot that shows the beat confidence level for the first few hundred beats of Some Nights.
The red curve shows the confidence level of the beats. You can see that the confidence ebbs and flows in the song. Likewise we can look at the normalized loudness levels at the beat level, as shown by the green curve in the plot below:
We want to play the drums during the louder and high confidence sections of the song, and not play them otherwise. However, if just simply match the loudness and confidence curves we will have drums that stutter start and stop, yielding a very unnatural sound. Instead, we need to filter these levels so that we get a more natural starting and stopping of the drums. The filter needs to respond quickly to changes – so for instance, if the song suddenly gets loud, we’d like the drums to come in right away, but the filter also needs to reject spurious changes – so if the song is loud and confident for only a few beats, the drums should hold back. To implement this I used a simple forward looking runlength filter. The filter looks for state changes in the confidence and loudness levels. If it sees one and it looks like the new state is going to be stable for the near future, then the new state is accepted, otherwise it is rejected. The code is simple:
When the filter is applied we get a nice drum transitions – they start when the music gets louder and the tempo is regular and they stop when its soft or the tempo is changing or irregular:
This above plot shows the confidence and loudness levels for the Some Nights by Fun. The blue curve shows when the drums play. Here’s a detailed view of the first 200 beats:
You can see how transient changes in loudness and confidence are ignored, while longer term changes trigger state changes in the drums.
Note that some songs are always too soft or most of the beats are not confident enough to warrent adding drums. If the filter rejects 80% of the song, then we tell the user that ‘Bonzo doesn’t really want to play this song’.
Aligning the song and the beats
At this point we now have tempo matched the song and the drums and have figured out when to and when not to play the drums. There’s just a few things left to do. First thing, we need to make sure that each of the song and drum beats in a bar lines up so the both the song and drums are playing the same beat within a bar (beat 1, beat 2, beat 3, beat 4, beat 1 …). This is easy to do since the Echo Nest analysis provides bar info along with the beat info. We align the beats by finding the bar position of the starting beat in the song and shifting the drum beats so that the bar position of the drum beats align with the song.
A seemingly more challenging issue is to deal with mismatched time signatures. All of the Bonham beats are in 4-4 time, but not all songs are in 4. Luckily, the Echo Nest analysis can tell us the time signature of the song. I use a simple but fairly effective strategy. If a song is in 3/4 time I just drop one of the beats in the Bonham beat pattern to turn the drumming into a matching 3/4 time pattern. It is 4 lines of code:
if (timeSignature == 3) {
if (drumInfo.cur % 4 == 1) {
drumInfo.cur+=1;
}
}
Here’s an example with Norwegian Wood (which is in 3/4 time). This approach can be used for more exotic time signatures (such as 5/4 or 7/4) as well. For songs in 5/4, an extra Bonham beat can be inserted into each measure. (Note that I never got around to implementing this bit, so songs that are not in 4/4 or 3/4 will not sound very good).
Playing it all
Once we have aligned tempos, filtered the drums and aligned the beats, it is time to play the song. This is all done with the Web Audio API, which makes it possible for us to play the song beat by beat with fine grained control of the timing.
Issues + To DOs
There are certainly a number of issues with the Bonhamizer that I may address some day.
I’d like to be able to pick the best Bonham beat pattern automatically instead of relying on the user to pick the beat. It may be interesting to try to vary the beat patterns within a song too, to make things a bit more interesting. The overall loudness of the songs vs. the drums could be dynamically matched. Right now, the songs and drums play at their natural volume. Most times that’s fine, but sometimes one will overwhelm the other. As noted above, I still need to make it work with more exotic time signatures too.
Reception
The Bonhamizer has been out on the web for about 3 days but in that time about 100K songs have been Bonhamized. There have been positive articles in The Verge, Consequence of Sound, MetalSucks, Bad Ass Digest and Drummer Zone. It is big in Japan. Despite all its flaws, people seem to like the Bonhamizer. That makes me happy. One interesting bit of feedback I received was from Jonathan Foote (father of MIR). He pointed me to Frank Zappa and his experiments with xenochrony The mind boggles. My biggest regret is the name. I really should have called it the autobonhamator. But it is too late now … sigh.
All the code for the Bonhamizer is on github. Feel free to explore it, fork and it make your own Peartifier or Moonimator or Palmerizer.
Girl Talk in a Box
Here’s my music hack from Midem Music Hack Day: Girl Talk in a Box. It continues the theme of apps like Bohemian Rhapsichord and Bangarang Boomerang. It’s an app that lets you play with a song in your browser. You can speed it up and slow it down, you can skip beats, you can play it backwards, beat by beat. You can make it swing. You can make breaks and drops. It’s a lot of fun. With Girl Talk in a Box, you can play with any song you upload, or you can select songs from the Gallery.
My favorite song to play with today is AWOLNATION’s Sail. Have a go. There’s a whole bunch of keyboard controls (that I dedicate to @eelstretching). When you are done with that you can play with the code.
Going Undercover
My Music Hack Day Stockholm hack is ‘Going Undercover‘. This hack uses the extensive cover song data from SecondHandSongs to construct paths between artists by following chains of cover songs. Type in the name of a couple of your favorite artists and Going Undercover will try to find a chain of cover songs that connects the two artists. The resulting playlist will likely contain familiar songs played by artists that you never heard of before. Here’s a Going Undercover playlist from Carly Rae Jepsen to Johnny Cash:
For this hack I stole a lot of code from my recent Boil the Frog hack, and good thing I could do that otherwise I would never have finished the hack in time. I spent many hours working to reconcile the Second Hand Songs data with The Echo Nest and Rdio data (Second Hand Songs is not part of Rosetta stone, so I had to write lots of code to align all the IDs up). Even with leveraging the Boil the Frog code, I had a very late night trying to get all the pieces working (and of course, the bug that I spent 2 hours banging my head on at 3AM was 5 minutes of work after a bit of sleep).
I am pretty pleased with the results of the hack. It is fun to build a path between a couple of artists and listen to a really interesting mix of music. Cover songs are great for music discovery, they give you something familiar to hold on to while listening to a new artist.
Johnny Cash Has Been EVERYWHERE (Man)!
My favorite hack to come out of last week’s Music Hack Day London (and perhaps one of my favorite music hack of all time) is the hack by Iain Mullan called “Johnny Cash Has Been EVERYWHERE (Man)!“. This hack has all the ingredients of a great music hack – great music, great execution, a bucket full of whimsy, and absolutely nothing about it that would make an MBA start writing a business plan. It’s practically a perfect hack. The only flaw is that Johnny Cash would never measure his distance travelled in kilometers. Check it out: Johnny Cash Has Been EVERYWHERE (Man)!“.
High Five Hero
A guest post by Jennie Lamere. This weekend, I had the pleasure of attending MIT’s Music Hack Day with my friend Barbie. We, along with about 250 others, worked all weekend to develop a music hack. In the twenty four hours we had, Barbie and I collectively slept a mere 6 hours. After endless cups of coffee and soda, we finally emerged with our hack, “High Five Hero.”
Our hack was a remixing tool driven by MaKey MaKey. MaKey Makey, created by Jay Silver and Eric Rosenbaum, is a device that plugs into computers, allowing virtually anything to be used in place of a keyboard. For our hack, we took four beats from various songs and made it so that each completed circuit yielded a different beat – the song could be remixed by completing the circuit in different orders. While neither Barbie nor I knew Javascript or html at the beginning of the weekend, we were well-versed in it by the end. A few hours in, we had the basic code written, so we decided to add more to the hack. We added a game mode, in which the two users must complete the circuit in specific patterns to play the song. We also added an “Expert’s Only” mode, in which combo moves must be done in order to play a beat.
While writing the code itself wasn’t exactly easy, we left the hack day around 8:00 on Saturday feeling very confident – all we had left to do was add the hardware component. Our idea was to have the MaKey Makey hooked up so that when we high fived, a circuit would be completed. However, we couldn’t get the MaKey MaKey set up in such a manner that the beats would all play at the same time. After gloves, tape, wire, more tape, aluminum and even more tape, we finally got the MaKey MaKey set up. This time, we were the problem – we could not get our timing to align in a way that would make the music sound good. We decided to abandon our original idea, and try to hook the MaKey MaKey up to something else besides our hands. After hours of brainstorming, we decided to go back to our original idea, but place the points for the MaKey MaKey in different places – one on each hand, and one on each knee. This seemed to work better, and the sound produced began to sound like music.
Barbie and I were extremely proud of our first music hack- High Five Hero. Despite being extremely nervous for our demo, showing off our hack seemed to go over well! We loved being able to talk to the other hackers, and seeing what they did. We are excited to attend our next Hack Day together!
Editor: I took a video of the demo presentation of High Five Hero. Apologies for the unsteady hand:
Hackathons are not nonsense
Dave Winer says that Hackathons are nonsense. Specifically he says:
Hackathons are how marketing guys wish software were made.
However, to make good software, requires lots of thought, trial and error, evaluation, iteration, trying the ideas out on other users, learning, thinking, more trial and error, and on and on. At some point you say it ain’t perfect, but it’s useful, so let’s ship. That process, if the software is to be any good, doesn’t happen in 24 hours. Sometimes it takes years, if the idea is new enough.
Dave says that software is hard and you can’t you can’t expect to build shippable software in a day. That’s certainly true, and if the goal of a hackathon was to get a bunch of developers together to build and ship commercial software in a day, I’d agree with him. But that’s not the goal of any of the hackathons I’ve attended.
I’ve participated in and/or helped organize perhaps a dozen Music Hack Days. At a Music Hack Day, people who are interested in music and technology get together for a weekend to learn about music tech and to build something with it. The goal isn’t to ship a software product, it is to scratch that personal itch to do something cool with music. The people who come to a Music Hack Day are often not in the music tech space, but are interested in learning about all the music APIs and tech available. They come to learn and then use what they’ve learned to build something. At the most recent Music Hack Day in San Francisco, 200 hackers built 60 hacks including new musical instruments, new music discovery tools, social music apps and music games.
Music Hack Days are not nonsense. They are incredibly creative weekends that have resulted in a 1,000 or more really awesome music hacks. Consider the hackathon to be the Haiku of programming. Instead of 17 syllables in 3 lines, a hacker has 24 hours. (Maybe we should call them Haikuthons;) I think the 24 hour constraint contributes to the creativity of the event.
Here are some of my favorite hacks built at recent Music Hack Days. Plenty of whimsy but no nonsense here:
- Drinkify – Answers the question “I’m listening to X, what should I drink?
- Invisible Instruments – Just what it says, musical instruments that you can’t see
- Bohemian Rhapsichord – Turns Queen’s Opus into a musical instrument
- Musaic – Discover music through photomoasics
- MIDEM Music Machine – a beautiful visualization of a song
- Tourrent Plans - Plan your tour based on where all the torrent downloaders are
- Stringer – a virtual string instrument
- The Swinger - Makes any song swing
Paul vs. Billboard
Posted by Paul in code, data, fun, The Echo Nest on February 12, 2012
Another weekend, another Music Hack Day. This weekend I’m at Tokbox headquarters in San Francisco at the 3rd annual Music Hack Day San Francisco, where 200 music hackers are building the future of music.
For my hack, I thought I would try to predict who would win the Grammy awards (the annual music awards presented by The Recording Academy) which is being held this evening. To do this, I used the Echo Nest APIs to gather of lots of news and blog posts for each nominated artist. I then peered into the articles looking for mentions of the Grammy nominated items. I tallied up the mentions and combined this with the overall artist hotttnesss to give me a ranked order of each nominated item, which I could then use to create my prediction.
Since Billboard has also made some Grammy predictions, I thought it’d be interesting to do a post-facto comparison on how well each of us predicts the winners – thus the hack title ‘Paul vs. Billboard’.
The hack is online here: Paul vs. Billboard
Be sure to check out all of the other music hacks being created this weekend:
The Midem Music Machine
Just a quick post before it is demo time. This weekend at MIDEM Hack Day, I teamed up this weekend with the famous Mr. Doob to build a music hack. We created the Midem Music Machine. It creates a beautiful visualization of music using The Echo Nest analyzer and Three.js. Here’s a pic:
As you can see, our hack was inspired by the Animusic folks. Working with Mr. Doob was awesome. He did just amazing stuff.
You can see the Midem Music Machine online here: Midem Music Machine. You’ll need a browser that supports WebGL like Chrome.
My Music Hack Day London hack
Posted by Paul in code, data, events, The Echo Nest on December 4, 2011
It is Music Hack Day London this weekend. However, I am in New England, not Olde England, so I wasn’t able to enjoy in all the pizza, beer and interesting smells that come with a 24 hour long hackathon. But that didn’t keep me from writing code. Since Spotify Apps are the cool new music hacking hotttnesss, I thought I’d create a Spotify related hack called the Artist Picture Show. It is a simple hack – it shows a slide show of artist images while you listen to them. It gets the images from The Echo Nest artist images API and from Flickr. It is a simple app, but I find the experience of being able to see the artist I’m listening too to be quite compelling.
Slightly more info on the hack here.
How to avoid demo fail
So you’ve spent all weekend working on an awesome hack. It is demo time. You have exactly 2 mins to show it off to your hacking peers. You are at the podium, you look out at the faces in the crowd that are anticipating your demo. And nothing works. The 2 minutes stretch to two hours as you wait for that web page with your hack to load. You stammer a “what you would see if this was working” explanation and you leave the stage to a smattering of applause a much more humble person.
As one of the organizers for the Music Hack Day hackathon, I’ve sat through about 500 music hack demos in the last few years and I’ve probably seen at least 50 demo failures. Most of them could have been avoided with just a little bit of preparation. So here’s a list of the most common ways for demos to fail and how you can avoid them.
Hardware Failures
Hooking your computer up to a projector and audio projector should be easy, but sometimes it can be the most vexing of all. If you have the opportunity, do an A/V check before the demo session so you will have all the kinks worked out. Here are the most common failures:
- Missing Adapter – Don’t be surprised if you get to the podium to give your demo and the only thing there is a VGA connector. It never hurts to have an adapter that works with your computer/device in your pocket just in case. (but if you leave your adapter at the podium, you will never see it again).

- Projector won’t sync – it is the worst feeling in the world to connect your laptop to a projector and have it not see the projector. You should know how to force your computer to detect displays.
- No Internet – you are sitting in the audience hitting refresh on your demo web page ever 3 seconds. All is well. It is your turn to give your demo, you close your laptop, walk up to the podium, open it up, plug it in and find that your web page is no longer loading. I’ve see this happen dozens of times. It is easy to forget that when you close your laptop you may lose your network connection and may have to re-login to the local Internet provider before you get access. If you are running a non-web based demo that needs the Internet, this may be hard to notice. What’s worse, when there’s a big demo audience, with lots of laptops, iPads and iPhones, you may no longer even be able to reconnect to the local network. All the local IPs may be used up.

- Non-mirrored display – Lots of hackers have dual display setups. This can work against you when it is time to give a demo. What you see on your laptop in front of you is not what your audience can see. Moreover, the display topology probably won’t match the demo room layout so you may find you can’t even find a way to get your mouse onto the proper screen. Before you give a demo, make sure display mirroring is on. Pro-tip – on a Mac hit CMD-F1 to toggle mirror mode.
- Unexpected display resolution – Projectors usually have a much lower resolution than your desktop. If you are running your demo in a browser, usually you can adjust to a lower resolution, but if your app is written to expect a fixed display size (such as common with a 3D library, or Processing), your app may just not work. Be especially careful if your app needs to switch into fullscreen mode.
- Colors don’t show properly – I’ve seen demos with beautiful visualizations fail because projectors couldn’t show the colors well. If you are relying on colors and textures in your app an A/V check is mandatory.

- No audio jack – At a Music Hack Day you can expect that there will be an audio jack that pipes your laptop audio to the P/A system, but this is not always the case for other hacking events. If you are at a non-music hacking event, double check to make sure that there is an adequate audio hookup. There’s nothing that sounds worse than a demo where you have to hold a microphone up to your laptop speakers so the audience can hear your music.
- Audio Problems – (Added on 12/6/11) (This tip from Yuli Levtov). For those doing hacks based on certain audio-based programming languages e.g. Pure Data, SuperCollider, MaxMSP etc., plugging and un-plugging the mini-jack in a laptop can make these applications behave strangely, as some OSs think the soundcard is being swapped.The solution to this is either a) use a USB soundcard and plug into the headphone jack output at the podium, or b) leave a headphone splitter (small, inexpensive piece of kit) plugged into the headphone output of your laptop at all times, and simply plug the podium minijack into the headphone splitter when you come to give your demo. This will prevent your OS thinking the soundcard has changed, and avoid any nasty needs to re-boot your whole music masterpiece.
- Too many things to hook up – No, you probably don’t need your power supply for a 2 minute demo. Probably don’t need your mouse either. Think twice about that turntable, those lasers, the full rack of keyboards and midi sequencers. Every extra item you bring to the podium doubles the chances of demo fail. Some of the best hacks ever were essentially slide show presentations

Podium Failures
Even if you have successfully hooked up your gear to the projector and audio you are not out of the woods yet. Giving a demo at a podium can be tricky
- Can’t type and hold a microphone at the same time – it is hard enough to type in front of a room full of people. The adrenalin is flowing and your hands are shaking. It is ten times worse if you are also trying to hold a microphone while typing. If there’s a podium or clip on microphone use it. Don’t try to type with a handheld microphone.

- That’s no podium, that’s a table – sometimes there’s no podium, your laptop will be on a desk. You can chose to give your demo standing up and do crouch typing, or sit at the desk where no one will be able to see you. Be ready for unusual setups.

- Notificatus Interruptus – Don’t forget to turn off growl, email and twitter clients that like to put up friendly messages in the middle of your demo.

- No place to put my mouse – If you really need to use a mouse, be ready to find that there’s no room at the podium for a mouse and a laptop.

- It’s chaos up there! – When timing is tight, you’ll find that you are trying to setup your demo while the previous demo is tearing down and while the MC is at the same time trying to get the on deck demo ready. Too many people, too many things to setup, too little time make for a very stressful couple of minutes. Don’t get flustered.

Presentation Failures
Once you have everything setup and connected properly it is time to give actually give your demo. There are still ways to snatch success from the jaws of failure:
- Practice – Giving a demo can be challenging. You are standing at a podium in front of a couple hundred people. Your showing off something that you’ve only just finished building. There may be bugs that you need to work around, the screen may be at the wrong resolution, your hands may be shaking. You may get flustered because the audio volume was too low. With all of this stuff going on, you will forget to demo that cool feature, or you will run out of time before you get to the showstopper. The key to a great demo is Practice Practice Practice. Know what you are going to demo, know what the results will be. Know what you are going to say. Time it, give yourself a few extra seconds of time. Run through it all 10 times.

- Tell us what your demo does – You’ve been living your demo all weekend, you know what it does, but the 200 people in the audience don’t. Tell us what it does. Tell us in a couple of different ways. Make it clear why it is new, cool and worth paying attention to.

- Budget the time properly – You have 2 minutes. We don’t need to know about the github issue you had. We don’t need to know about the difficulties you had installing numpy and scipy. Get to the meat of the demo.
- Don’t waste time telling us about what you failed to do – I’ve heard lots of demos where I was told about this nifty feature that they couldn’t get to work. Don’t demo your failures, demo you successes.
- Make your demo do one thing – Two minutes is not a long time. Especially when you are showing something complex. You may have 5 nifty features in your demo, but you will never be able to demo them all. Pick the coolest feature in your demo and plan to show it a couple of times in a couple of different ways.

- Demo it! – Don’t tell us what your demo is going to do. Show it to us.

- Be enthusiastic – Excitement is contagious. If you are excited about what you are showing, we will get excited too. If you are bored, we will be checking our twitter feed.















