Posts Tagged musichackday
You have 24 hours to build the future of music
Posted by Paul in data, fun, hacking, Music, music hack day, The Echo Nest on November 12, 2013
A Music Hack Day is unlike most other hackathons. There are no mega-prizes for the best hacks. There are no VCs wandering the hacker hallways trolling for the next startup. There are no briefs that describe the types of apps that you should build. Hackers don’t go to a Music Hack Day to win big prizes, or to launch their startup. Hackers go to Music Hack Days because they love music and they love to build stuff. At a Music Hack Day these passionate builders get to apply their talents to music, surrounded by like-minded peers and build their version of the future of music. The currency at a Music Hack Day is not money or VC attention, the currency is creativity. The Music Hack Day prize is knowing that you’ve built something cool enough to delight other music hackers.
So what happens at a Music Hack Day? How does it all work? What kind of hacks do people build? Read on to see exactly what happened at the Boston Music Hack Day 2013, held this last weekend.
Boston Music Hack Day
This weekend, hundreds of folks who are passionate about music and technology got together in Cambridge MA for Boston Music Hack Day 2013. The event was hosted at the Microsoft NERD – a wonderful facility that Microsoft makes available for all sorts of programmer events. Registration started at 9AM and by 10AM hackers were breakfasted and ready to go.
The event started off with some opening remarks by your truly, describing how a Music Hack Day works and how to have a successful event (meet other people, learn new stuff, build something, make sure you finish it, demo it and have fun).

Build Something! – key advice for a Music Hack Day

Hackers riveted by Paul Lamere’s opening remarks
Short technology presentations
Next up, organizations that had some sort of music technology such as an API or new gizmo that might be interesting to music hackers spent a few minutes talking about their technology. For many hackers, this was their first exposure to the music ecosystem – they don’t know what APIs are available for building apps so learning about music streaming APIs from companies like SoundCloud, Rdio and Spotify, and learning about all the music data available from APIs like The Echo Nest and the Free Music Archive is really important.

Matt talks about the Reverb.com API
There were a few interesting devices available for hackers at the event. Techogym brought a high tech treadmill with its own API hoping that music hackers would build music-related exercise apps. Muzik brought a set of headphones that are instrumented with accelerometers and other sensors allowing for apps to adapt to the actions of the listener.

Hackers trying out the Technogym
Project Pitches
Sometimes hackers come to a Music Hack Day with ideas ready to go. Sometimes hackers come with their skills but no ideas. At the Project Pitch session, hackers had a minute to pitch their idea or to offer their skills. About 20 hackers braved the front of the room describing their idea or their skill set. One hacker described his project as help me with my homework (and yes, this hacker did find a teammate and they ultimately built a nifty hardware hack that satisfied the homework requirement too).

The homework as hack demo
Tech Deep Dives
Next up on the schedule were the Tech Deep dives. Organizations had a half-hour to give a deeper view of what their technology is capable of. Some hackers want to know more about how to do particular things with an API or technology. This is their opportunity to find out all about the nuts and bolts, to ask questions from the experts. The Tech Deep Dives are strictly optional – many hackers skip them and instead start forming teams, sharing ideas, initializing their repos and writing code.

Kevin does the Rdio API deep dive
Hack Time
After all the preliminaries are over it was finally time to start hacking.
Hackers formed teams, large and small.
The competition for the best vest was fierce:
They staked out a comfortable workspace in chairs …
Or on the floor …
There were some very creative hardware hacks:
Software hacks:
Plenty of good food
And lots of fun
Overnight Hacking
The Microsoft NERD was only available until 9PM – after that we moved over to hack/reduce – a wonderful hacking space a five minute walk away. There we were greeted by a perfect hacking space with lots of great wifi, great hacker lighting, and lots of beer. Hacking continued all night. Some hackers did try to get some sleep (either at the hack, or back at home), but some hardcore hackers stayed the whole night.
By 9AM on Sunday morning, the hackers were back at the NERD, for lots of coffee, some breakfast and then more hacking.
Hacking ends
At 2:30, hacking was officially over, and teams submitted their projects to Hacker League. Sixty hacks were submitted.
Demo Session
By 3PM the 200 hackers had all gathered back into the big room joined by a hundred folks who had come just to see the demo session. Hackers had two minutes to show their stuff. It is a hard demo to give. You are giving a demo of software that you’ve just finished building. It might have some bugs. The WiFi is a little flaky, you haven’t slept in 24 hours, your hands are shaking from too much coffee and too much nervousness, you have to type while holding a microphone and your laptop just won’t sync with the projector just right, and the audio isn’t coming out of the speakers, and the colors look all wrong on the screen. All in front of 300 people. I’ve done it dozens of times and it still is a really scary demo to give. But it is incredibly exhilarating too – to take nothing but an idea and turn it into something that can amaze or amuse a room full of tech elite in 24 hours. It is quite a rush.

Here I am giving my demo, heart pounding, blood racing …
There were two A/V setups so while one team was presenting, the next team was setting up. This allowed us to get through 60 demos in just over two hours. There was a very low incidence of demo fail. And only two inappropriate demos (one was a 2 minute powerpoint presentation with no tech built, the other was a 2 minute tech commercial for a product). I was worried that we might have a #titstare moment with one hack that seemed to contain questionable content but that hacker apparently decided not to present.
The 60 hacks represented a wide range of domains. There were games, music learning tools, programs designed to create, manipulate, remix and even destroy music. I’d love to cover them all, but there are just too many.
The full list is on hacker league. Here are some of my absolute favorites:
String Theory – A musical instrument and sound sculpture build from yearn and stretch sensors and powered by an Arduino.

String Theory
The Lone Arranger – a terminal app that allows you to easily rearrange your audio. By a father and son hacking team.
The Secret History of Music – combs biographies, lyrics, and commentary from song meanings from two artists, combines them into one fictional artist, and uses Markov chain magic to generate a 50K novel about this new fictional band.
LED Soundsystem – this hack attempts to generate a light show synchronized to the music. It has a special place in my heart because the hacking team was working on the same problem I was working on for my abandoned hack – i.e. automatically finding the ‘drop’ in a song. Unfortunately, this team had a demo fail – but they are smart guys and I expect to see good stuff from them at the next hack day.
eHarmonica – an electronic harmonica!
Enter the dragon – In today’s world, everyone deserves a spectacular entrance. And we intend to give it to them. Enter the Dragon uses bluetooth technology to detect when a user enters the room and plays their personalized entrance music.
Dadabots – Dadabots are bot accounts on creative websites that make procedural creations or remixes of other creations
ios SoundPuzzle – A simple iOS ear training game built programmatically from the free music archive and the echonest remix api.
danceomatic – totally awesome automatic choreography from an mp3 and a web based stick figure performance.
Jotunnslayer – Never again listen to power metal without slaying ice giants. Die in battle. Earn your place in Valhalla.
Give Me Liberty or Give Me Death Metal – Political representation via musical exploration
Echos – Choose your favorite song and shoot to the beat! Fight enemies that respond to and are controlled by the music! Listen closely and experience unparalleled power as you get into the groove! Enjoy addictive arcade-style game-play in this twist on a classic formula.
TweetTones – a native iOS application that generates synthesized music from tweets in real-time.
Short-Attention Span Playlist Scanner – Glenn made a radio scanner that find and plays just the choruses.
ionian Eclipse – A web-based multiplayer top-down space shooter with procedurally generated enemies and interactions driven by music events.
CFD is Colorful Fluid Dynamics: A HTML5 Music Visualizer and Spotify Plugin – A music visualizer written entirely in vanilla javascript/canvas that is based on computational fluid dynamics and a complex particle system.
ColorMe – Ever wondered what your music looked like? Now you can look at songs by your favorite artist with this super fun web app, powered by the Echo Nest.
How Repetitive – measures how often audio segments repeat themselves within in a given song.
Jason’s music visualizer – an html/css visualizer on steroids.
And last, but by no means least, Jonathan’s awesome MIDI Digester that converts audio to MIDI and back, over and over to generate some very strange sounds. The very essence of the music.
There are so many excellent hacks, I’m sure I’ve missed many notables. Luckily, Evolver.fm covered the event, so expect to see Eliot’s writups on all the best hacks on Evolver.fm.
Prizes
At the end of the mega demo session, there’s a brief prize awarding ceremony where a half-dozen organizations give out modest prizes for hackers that made cool stuff using their tech.
Finally we adjourned to the local pub for some food, beer and hacking recaps.
Special thanks to the organizers of the event. The Music Hack Day would not happen without Elissa and Matt. They do all the hard work. Finding the venue, wrangling the sponsors and volunteers, making a mega Costco food run, dealing with the A/V, running the registration, selecting and hiring the caterers, designing t-shirts and so much more. There’s a huge amount of work that goes into planning the event, much more than meets the eye. Elissa and Matt are the unsung heroes of Music Hack Day. We should make a music hack to sing their song.
Thanks also to the event sponsors: Rdio, Spotify, Microsoft, hack/reduce, Free Music Archive, SoundCloud, Mailchimp and The Echo Nest, and the many volunteers who came and helped us run the whole show.

Some of the awesome and unusually attractive volunteers at Music Hack Day Boston
More Music Hack Days
Interested in going to a Music Hack Day? Check out the Music Hack Day calendar for upcoming events. There’s one in Helsinki this weekend, and there’s one in London in just a few weeks. More events are rumored to be in the planning stages for 2014.
(Photos mostly by Michelle Ackerman, a few by me)
The Awesome Chart Explorer
Posted by Paul in code, fun, hacking, Music, music hack day, The Echo Nest on October 19, 2013
I just finished coding up my Music Hack Day NYC hack called The Awesome Chart Explorer. It’s a web app that combines Billboard and Echo Nest data into a visual wonderland. (yes, I’m a little tired). Check it out here. Almost time to give the demo, so more about the tech behind the hack later on.
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:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
function runLength(quanta, confidenceThreshold, loudnessThreshold, lookAhead, lookaheadMatch) { | |
var lastState = false; | |
for (var i = 0; i < quanta.length; i++) { | |
quanta[i].needsDrums = false; | |
} | |
for (var i = 0; i < quanta.length –1; i+=2) { | |
var newState = getState(quanta[i], confidenceThreshold, loudnessThreshold); | |
if (newState != lastState) { | |
// look ahead | |
var matchCount = 0 | |
var curCount = 0; | |
for (var j = i + 1; j < quanta.length && j <= i + lookAhead; j++) { | |
var q = quanta[j]; | |
var nstate = getState(q, confidenceThreshold, loudnessThreshold); | |
if (nstate == newState) { | |
matchCount++; | |
} | |
curCount++; | |
} | |
if (matchCount > lookaheadMatch) { | |
curState = newState; | |
} else { | |
curState = lastState; | |
} | |
} else { | |
curState = newState; | |
} | |
quanta[i].needsDrums = curState; | |
quanta[i+1].needsDrums = curState; | |
lastState = curState; | |
} | |
} | |
function getState(q, confidenceThreshold, loudnessThreshold) { | |
var conf = q.confidence; | |
var volume = q.oseg.loudness_max; | |
var nstate = conf >= confidenceThreshold && volume > loudnessThreshold; | |
return nstate; | |
} |
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!
[youtube http://www.youtube.com/watch?v=KozsJ-pIID4]
Editor: I took a video of the demo presentation of High Five Hero. Apologies for the unsteady hand:
[youtube http://www.youtube.com/watch?v=fFO46bGINzk]
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.