Posts Tagged musichackday
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
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:
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.
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.
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.
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
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.
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.
I’ve spent the weekend hacking on a project at Music Hack Day Montreal. For my hack I created an application with the catchy title “Search for music by drawing a picture of it”. The hack lets you draw the loudness profile for a song and the app will search through the Million Song Data Set to find the closest match. You can then listen to the song in Spotify (if the song is in the Spotify collection).
Coding a project in 24 hours is all about compromise. I had some ideas that I wanted to explore to make the matching better (dynamic time warping) and the lookup faster (LSH). But since I actually wanted to finish my hack I’ve saved those improvements for another day. The simple matching approach (Euclidean distance between normalized vectors) works surprisingly well. The linear search through a million loudness vectors takes about 20 seconds, too long for a web app, this can be made palatable with a little Ajax .
The hack day has been great fun, kudos to the Montreal team for putting it all together.
I’m just back from a whirlwind trip to Cannes where I took part in the first ever MIDEM Hack Day where 20 hotshot music hackers gathered to build the future of music. The hackers were from music tech companies like Last.fm, SoundCloud, Songkick, The Echo Nest, BMAT, MusixMatch, from universities like Queen Mary and Goldsmiths, one of the four major Labels, and a number of independent developers. We all arrived to the exotic French Riviera, with its casinos, yachts and palm trees. But instead of spending our time laying on the beach we all willingly spent our time in this wonderful room called Auditorium J:
First thing was we did was rearrange the furniture so we could all see each other making interactions easier. It wasn’t long before we had audio hooked up – with hackers taking turns at being the DJ for the room.
Dave and I took a break from the hacking to give a talk on the ‘New Developer Ecosystem’. We talked about how developers were becoming the new gatekeepers in the world of music. The talk was well attended with lots of good questions from the audience. (Yes, I was a bit surprised. I was half expecting that MIDEM would be filled with the old guard – reps from the traditional music industry that would be hostile toward self-proclaimed new gatekeepers. There were indeed folks from the labels there and asking questions, but they seemed very eager to engage with us).
While Dave and I were talking, the rest of the gang had self-organized, giving project pitches, forming teams, making coding assignments and perhaps most importantly figuring out how to make the espresso machine work.
Here are some of the project pitches:
Some teams started with designs with dataflow diagrams, while others dived straight into coding (one team instead, starting composing the music for their app)
Dataflow diagrams, system architecture, and UI minispecs became the artwork for the hacking space.
After the lightening design rounds, people settled into their hacking spots to start hacking:
By mid-afternoon on the first day of hacking, the teams were focused on building their hacks.
There were some interesting contrasts during the day. While we were hacking away in Auditorium J, right next door was a seminar on HADOPI. (the proposed French law where those accused of copyright violations could be banned from the Internet forever).
As we got further in to our hacks, we gave demos for each other
Over the course of the weekend, we had a few ‘walk-ins’ who were interested in understanding what was going on. We did feel a little bit like zoo animals as we coded with an audience.
Taylor Hanson dropped by to see what was going on. He was really interested in the idea of connecting artists with hackers/technologists. After the visit we were MMMboppping the rest of the day.
Towards the end of the first day, the Palais cleared out, so we had the whole conference center to ourselves. We made the beer run, had a couple and then went right back to hacking.
Finally, the demo time had arrived. After more than 24 hours of hacking we were ready (or nearly ready). Demos were created, rehearsed and recorded.
We presented our demos to an enthusiastic audience. We laughed, we cried …
There were some really creative hacks demoed – Evolver.fm has chronicled them all: MIDEM Hack Day Hacks Part 1 and MIDEM Hack Day Hacks Part 2. At the end of the hack day, we were all very tired, but also very excited about what we had accomplished in one weekend.
Thanks much to the MIDEMNet organizers who took care of all of the details for the event – sandwiches, soda, coffee, flawless Internet. They provided everything we needed to make this event possible. Special thanks to Thomas Bonte (unofficial Music Hack Day photographer) for taking so many awesome photos.