Posts tagged Music
Echo Nest song API
May 2nd
At last weekend’s Amsterdam Music Hack Day the Echno Nest guys announced their new and extended API. The song API looks like it could be a lot of fun, allowing not only searches for songs by title/artist, but also similarity, loudness, tempo and a range of other attributes.
Filesharing legislation and why it’s unworkable
Feb 14th
According to leaked documents obtained by The Times, the UK government is planning a green (discussion/consultation) paper proposing strong action against “illegal file-sharing.” According to the leaked documents they want ISPs to take the primary responsibility for monitoring usage and to ban any of their users who continually share copyrighted materials without permission. Whatever your position on copyright enforcement in a digital age, this is a ludicrous idea.
Logistically such proposals will be almost impossible to enforce effectively. Setting aside the issue that many of us encrypt as much as possible of the data going out from our computers, it will effectively require ISPs to monitor all traffic going through their networks in a far more intrusive way than they currently do.
Most ISPs watch traffic and do some work to “shape” it to make sure that, say, email takes priority over bittorrent, but they can do that at a high-level without looking closely at the content of that traffic. Under these proposals they would have to track all the data moving between your computer and the internet, and piece it all together to detect any material that could conceivably be copyrighted. The privacy issues around that are startling, but the technical issues are only starting.
Once the ISPs have that data, they then need to work out if it is indeed copyrighted and have a mechanism for working out if their users have the rights to distribute it. If I rip the new Ratatouille DVD and stick it on bittorrent it’s fairly easy for them to identify that, and there’s a good chance I’m infringing copyright. But what if I’m a Pixar employee uploading it to an online storage site so that I can pass it along to selected technical or media contacts? Or how’s about an event like Greenbelt were to ask a group of us to make a new promotional video available? That would probably contain multiple copyrighted items under an appropriate license, but torrents may be the most appropriate distribution mechanism and volunteers (rather than staff) may be the best people to get it out there.
In either case, there’s the hassle for me in having to provide a paper trail to my ISP each and every time I want to do something that might appear slightly suspicious, and of course there are the ISPs who will have to be able to process that paper trail, check its veracity, and potentially then provide an audit trail on up to whoever manages the regulations. They’re going to have to charge me more in order to cover those costs, and I’m going to have to put in a lot more effort to perform tasks that are currently simple and will remain entirely legitimate.
TechCrunch UK is among the commentators wading in to criticise the plans. Their technical argument is similar to mine, but the economic one is quite different. Whether or not music ends up mostly being available for “free” there are numerous issues we’ll need to address, particularly that while the cost of distribution may come down that is only part of the cost of production.
Regardless, this issue stretches well beyond music, and the point stands that this is an example of government’s response to new challenges being driven by the desires of companies about to go out of business, and not by a real desire to engage with the future of the creative industries.
Book Review: Practical Ruby Projects
Jan 31st
The past few years have seen the English-language Ruby book market explode. Before the phenomenal success of Rails it was perfectly possible to own every available title (and not use much storage space), but now that would be quite a challenge and lead to considerable redundancy. Having worked my way through quite a few Rails books of late, reading Practical Ruby Projects—a Ruby book that doesn’t even mention web frameworks—was both a pleasant diversion and a highly illuminating experience.
Like the last volume I reviewed, this book is unabashedly aimed at experienced programmers. There’s a brief paragraph on “getting set up”, but no detailed guide to obtaining the tools. Instead we dive right in to a sequence of projects that includes: making music (dipping into calling C code from ruby), animation, simulation, building a strategy game (and adding a RubyCocoa frontend), genetic algorithms, and even implementing lisp and parsers. Once again the “apress roadmap,” a diagram intended to show how the skillsets in their different volumes build on one another, is misleading pitching this between “Beginning Ruby” and other volumes I’ve reviewed like Practical Ruby for System Administration and Pro Active Record. Don’t believe it. Though there’s little overlap in the material, this is a more advanced volume than either of those and readers should be prepared.
The pace of the book is measured and Topher Cyll does a good job of gradually building up the projects a step at a time. Along the way a variety of practices are demonstrated with many methods stubbed out for demonstration purposes before being filled in when they are needed, and considerable time spent on decoupling code. That latter piece is particularly in evidence in the chapters on building a turn-based strategy game and then developing a RubyCocoa front-end. Despite careful design early on further refactoring is needed to make it easy to apply the front-end and that process is carefully worked through.
Most of the book makes some use of existing libraries. The initial lisp chapter uses the sexp library and the subsequent section on writing a parse relies on rparsec. For the most part, however, use of the libraries is kept to a minimum, allowing for fairly self-contained code. Unit testing is largely ignored until the last chapter, where the need for tests when constructing a grammar/parser is explained and a test-first development model is encouraged. That works well to demonstrate the power of tests for complex (and often brittle) code.
This is not a book designed for public transport reading. Working through chapters on the bus I frequently found myself wanting to reach for my laptop to get a better grasp of how a piece of code worked. While the explanation is generally very good, with material of this complexity there is nothing like running the code and tweaking it to make sure you’ve understood exactly what each transformation does. It’s a book to take your time over, so be prepared!
A few editorial errors have crept in, suggesting a re-organisation of the contents late in the day. In particular an early reference to s-expressions seemed to presume that the lisp and/or parsing chapters were featured early. That’s not a big deal and will hopefully be corrected in later printings; the author does encourage skipping around within the book, but there is value in working through it roughly in order, and not just for the two “paired” chapters that explicitly build on one another.
Perhaps the most striking thing about this book is the reminder that even for those of us whose primary programming activity is web development, studying other areas can be extremely helpful. Not only is it helpful to see how other developers structure their code, but tools like genetic algorithms and parsers are likely to be very helpful where web applications require sophisticated processing and/or backend systems. And it never hurts to learn a little lisp. For the ruby developer who’s comfortable with the language and wants to stretch out a little, this book would be an excellent investment.
Disclaimer: I was sent a copy of this book for review by the publisher. You can find it at apress, amazon US, amazon UK and all sorts of other places. Pat Eyler’s review can be found here.
Announcing FutureMusicTalk
Jan 28th
Discussion about the future of the music industry abounds. Whether it’s advice for artists or labels, discussions of the release of new technologies, or predictions for the future, there’s a lot of it out there. It’s good to get a range of perspectives, but until now it’s been hard to know where to get started if you want to delve into that world.
Today I’m announcing the launch of Future Music Talk, a site pulling together blog entries from a range of thinkers and practitioners. For those familiar with such things it’s a variant of the Planet-style sites so popular in the web development community (it’s powered by Planet Venus).
I’m very pleased with the balance amongst the initial contributors, including as it does Gerd Leonard and Dave Kusek, authors of The Future of Music, Andrew Dubber whose recent series of definitions is a must-read, Bruce Warila, Steve Lawson, Justin Boland, and Million Media.
It doesn’t stop there, so if you are running a blog on a related topic, drop me a line at james@jystewart.net and we can see about getting you included. Over the next few weeks I’m hoping to add a few other features (including drawing in links tagged futuremusictalk on delicious).
So take a look over at www.futuremusictalk.com, subscribe to the feed, and join the conversation.
Why we’re not quite ready for everyone to build their own social networking site
Dec 10th
Whether or not you should build your own social networking site and/or make use of sites like facebook is currently a hot topic within the not-for-profit web developer/consultant world. The launch of sites like Amnesty International’s “unsubscribed”, which bears many hallmarks of a social networking site, combined with growing attention for facebook campaigns and tools like SuperBadger bring the options and potential into clear focus. Elizabeth Dunn’s post last month “social networks, walled gardens, and decision trees” makes a compelling argument that non-profits should be focussing on these questions now even if they’re not key for their current audience: sooner or later they will be and you don’t want to be playing catchup.
There are certainly many advantages to having your own social networking site. A facebook or myspace presence may attract attention, but the data you’ll be able to gather about your supporters and the potential for inserting your own branding are limited. Set up your own social network and you have full flexibility to integrate that data with your supporter databases, and to tune the site to your very specific requirements. But not only are they a significant investment of resources, there’s also a significant cost of time for supporters who will need to sign up for yet another site, identify their friends once again and give their attention to even more online data. Online campaigning’s great strength so far has been its low barrier to entry; for cause-specific social networks to really make sense their barriers need to fall.
That desire is definitely not unique to non-profits. As Brian Suda’s “Portable Social Networks: Take Your Friends With You” highlights, finding ways to let users move their data from site to site is a hot topic across the web development world. Sites like traveller network dopplr have succeeded in part by letting their (so far highly tech savvy) users import data from other social networks such as twitter. The real breakthrough will be when the mass-networks of the moment (as facebook is today) become similarly open. That won’t make it easy, but it will mean that there is suddenly a huge audience who can become fully signed up for your site with just a couple of clicks.
Right now most efforts hinge on a set of emerging standards, two of which will be familiar to anyone who’s been reading this blog for some time but which bear some more attention. There’s plenty of information around the web on these so I’ll just touch on them briefly:
Microformats are a way of taking plain old HTML and, by following some conventions, adding meaning to the content that could be understood by machines. While a human might be able to look at some information and infer that it is describing an event, machines aren’t so good at that, so we need standardised ways to say “this is describing an event, that bit is the date,” or “this link is to the homepage of my brother.” There were already ways to do that, but it involved adding extra things to your website. With microformats, so long as you (or your content management system) follow some simple conventions when creating a page, a machine can get the content out of the page as easily as a human reader can. That lets us identify friends/contact lists in a portable way, among other useful functions.
OpenID is a way to get rid of the frustration of having to create a username and password for every new site you visit. Instead when you visit a new site that you want to sign up for, you enter a URL that is your OpenID and that site will check with a central system (which may require you to log in) whether you do in fact own that OpenID. Rather than having to remember dozens of usernames and passwords, you’ll probably just have to remember one URL, one username, and one password. And because you’re using that same OpenID for lots of sites, when you sign up for a new site you can be identified on others. So if you sign up for a new site I’ve created using the same OpenID you use on livejournal my software can identify you on livejournal and import your posts from there. So there’s less work for you to tell that new site you’re creating a profile on how to find your blog and to import the posts, and an easy way to make your profile active and informative.
OAuth is the newest of the standards and goes hand-in-hand with OpenID. It allows you to grant one web application permission to access certain parts of your data in another application without giving your usernames and passwords all over the places. If you’ve ever used a site that redirected you to flickr to get your permission to do something with your photos, you’ve seen something like it. If OAuth is widely adopted, no longer will you have to give every social networking site your webmail username and password in order to have your address book checked for other users of the site, simply trusting that they won’t abuse it. Instead, it becomes easy to give a one-off permission while keeping your details as secret as they should be.
What these pieces add up to is a significant reduction in the psychological hurdles that might prevent your supporters from joining your new social network. Instead of pouring hours into their friendster profile only to find everyone has moved to myspace, and so not signing up for your site because they’d have to go through the whole process all over again, they can sign up with their OpenID, perhaps grant you a few permissions with OAuth (knowing that they’re not handing over the keys to their email, online photos, or whatever) and be signed up with an already complete profile.
In other words, persuading people to sign up and build their profiles is no longer the issue and you can focus on providing them with compelling reasons to keep coming back.
So if you’re wondering whether now is the time to start building out your campaign’s fancy new social networking site, it just may be, but chances are a few months from now will be a better time. As OpenID and OAuth become better established—and maybe even get adopted by some of the big players—your life is going to be easier and provided you pick web developers who’ve been keeping up you’ll be able to focus on your campaign strategy rather than coaxing visitors to spend another few hours re-entering the same old details.