Friday 25th September, 2015
Hookline broker deals between independent music artists and people who want to license the music e.g. broadcasters, film producers, advertising agencies, games developers, etc. They offer a 60:40 revenue split in the artist’s favour and a non-exclusive contract.
We 1 first chatted to Hookline back in April 2013 when they had a slightly different business model in mind and were looking at applying to the Digital R&D Fund for the Arts for a grant. At the time I vaguely remember that we encouraged them to focus on proving the business model before spending a lot of money on building software.
Since then they’ve been successfully signing up artists and licensing their music using relatively manual processes, making use of services like Google spreadsheets, Dropbox, Echosign, etc - I think it’s really impressive how far they’ve got.
Their music catalogue is now big enough that the manual processes are taking up a lot of their time. This, along with the fact that they now have a really good understanding of how they want to do everything, means that it’s a sensible point to automate some of the processes.
A Product Idea
Along the way it’s also become apparent that there’s not really any good commercial software out there to manage a music catalogue, especially not any representing good value-for-money. They’ve done some market research and have come to the conclusion that there’s a gap in the market for such a product.
We chatted to Amy and Rachel a few weeks ago and agreed to collaborate on building this product. The idea is that initially we’ll focus on automating Hookline’s manual processes, but in doing so we hope to build a product that could be useful to other music companies. Amy and Rachel will then be able to demo the product to their music industry contacts and hopefully generate some sales.
So Team Hookline joined us at GFRHQ from Tuesday to Friday and we started building the product. It was really refreshing to work on a new app and to work so collaboratively with the product owners.
One of the things Rachel has to do a lot is to respond to briefs by sending out a curated playlist of tracks matching the brief. Up until now she’s been creating a new Dropbox folder for each playlist, copying over the relevant tracks, and sharing the folder with the requester. However, that means ending up with multiple copies of the tracks. This isn’t great and is rapidly becoming unsustainable as they increasingly want to send out large WAV versions of the tracks.
Ideally what they wanted was a way to easily pick a set of tracks from their catalogue and have them served up on a playlist web page. The playlist page was to have audio players for previewing the MP3 files and download links for the WAV files, with all the audio files hosted on Amazon S3.
We decided to start with a simple Rails app, but to do without ActiveRecord initially by querying their master Google spreadsheet from within the Rails app using the google_drive gem and OAuth 2. This worked out really nicely and allowed us to make quite rapid progress. It also meant that we didn’t have to worry about keeping our database in sync with the master spreadsheet.
We also elected to start by simply generating a chunk of HTML to be pasted into a page on their existing Wordpress site. This seemed sensible, because if this is going to be a product used by other companies, we may well want to keep the public-facing pages in a separate app. Once we had a simple walking skeleton up and running, we deployed the app to Heroku.
Chris used the S3cmd sync command line tool to get all the relevant audio files from Dropbox onto S3. He also wrote a rake task to update the master spreadsheet with data about which audio files were available on S3. While he was doing all this, I looked for an audio player we could use. In the end I chose to use audio.js via the audiojs-rails gem, because it seemed to offer the best combination of cross-browser support and skin-ability.
The next step was to introduce a database (Postgres) into the Rails app and persist the playlists so they could be edited and re-generated. I got a bit stuck on this due to some ActiveRecord association and validation weirdness, but I was interested to come across ActiveRecord::AutosaveAssociation in the process.
We wanted to be able to display artwork next to the tracks on the playlist page, so Amy downloaded suitable image files from the Wordpress site and Chris used S3cmd again to upload them onto S3. Once Chris had added the images to the generated HTML and Amy had added audio.js to the Wordpress site, we could create pretty decent looking playlist pages via our amazing copy & paste technology™.
The week was a lot of fun and it was satisfying to have got something relatively end-to-end working pretty well. We plan to have another week working on the product in a week’s time, so I’m looking forward to that.
Anyway, that’s your lot for now. Until next time.