³ÉÈË¿ìÊÖ

"Intempo’s solution is the Rebel, a music sampling system that, once tuned into an FM station, records the 40 most played tracks and then edits out the DJ chatter and the ads."

Information visualisation conference featuring Ben Fry. April 19, Wiesbaden, Germany.

³ÉÈË¿ìÊÖ - ³ÉÈË¿ìÊÖ Radio 4 Programmes - Afternoon Play, Silver Street: It's Coming ³ÉÈË¿ìÊÖ
Asian Network's Silver Street soap crosses over to Radio 4 as an Afternoon Play.

Live radio streaming on the iPhone from Gcap

The internet makes everything free. Kevin Kelly on where the value will be.

³ÉÈË¿ìÊÖ - ³ÉÈË¿ìÊÖ Radio 4 Programmes - Thinking Allowed, 06/02/2008
Fascinating edition on craft and skill, including writing code. With sociologist Richard Sennett, author of The Craftsman, and Grayson Perry, artist and potter.

Device polls party guests' MP3 collections on their laptops (!) to create a collaborative playlist

More at

Our latest post is from Matthew Wood, our software engineering team leader, who's been spending a little time recently with XMPP (as picked up by Tom on his recent Foocamp trip). Over to Matt...

XMPP seems to have been attracting quite a lot of interest. It's how find out about new downloadable content, it's the peer-to-peer messaging protocol for , and it's even been touted as .

As a mechanism for passing realtime messages between very large numbers of humans and machines, XMPP also looks interesting to national radio networks that want to connect to their considerable audiences, a large proportion of which are listening live and synchronously.

To try and find out if there's anything in all this I've exposed the tracks our music networks are currently playing as XMPP events that you can pick up and play with.

You can follow these steps to get going:

• Download a tune-capable XMPP client - I've been using as it has a handy XML console you can use to watch messages pass back and forth across the wires.

• Register yourself an account on the XMPP server at hug.hellomatty.com. Psi will do this for you, but only if you ask it not to 'Probe the Legacy SSL Port' when it makes a connection.

• Add a ³ÉÈË¿ìÊÖ music network as a buddy. Try radio1@hug.hellomatty.com, or 1xtra@hug.hellomatty.com, or...

• Follow along with our playout systems in the comfort of your home!

Note: As Matt says, you need a standards-compliant XMPP client. I've just discovered that isn't - Tristan

To achieve anything more exciting than lighting up a tooltip you'll probably want to pick up an XMPP library and knock up a client yourself. You could try building something Flashy with . Or if, like me, you're still in your ruby phase you could try .

Next steps are to expose more of the inner workings of radio (when programmes start and end, the 'live text' that scrolls across DAB receivers). Maybe to start spawning conversations around specific programmes ('Chat LIVE to real live Audience Members about 'The Court of King Rudolf II' would be an invitation I might just click on).

But what do you think we should expose with XMPP? And what kind of clients could you build?

I've recently returned from a very enjoyable and educational trip to California where I was honored to be invited to attend the Social Graph Foo Camp. Although I do have to say that while I found the whole thing very exciting I was also, at times, left realising just how far behind some of the conversations I have become, it really is amazing how rapidly the issues and technology within this space are developing - and that's in the context of a fast moving industry.

It was, however, clear that the really big issues are social not technological: user expectations, data ownership and portability. Although a key piece of the technology puzzle in all this is the establishment of and which are going to play an ever increasingly important role in glueing different social networks together. And with the launch of (released under a Creative Commons license by the way) data portability is going to really explode; but with it expect more .

But the prizes for getting this right are great, as illustrated by this clip of of Plaxo presenting on friends list portability and who owns the data in social networks.

For my part what I took away from this and other discussion is that although on the surface moving data between one social network and another is no different from copying a business card into Outlook people's expectations make it different. People don't (yet) expect the data they enter in one site to suddenly appear in another. But they do expect to be able to easily find their friends within a new network. Google's Social Graph API will make it easier - but there will be a price, as :

"Google's Social Graph API... will definitively end "security by obscurity" regarding people and their relationships, as well as opening up the social graph to "rel=me" spammers. The counter-argument is that all this data is available anyway, and that by making it more visible, we raise people's awareness and ultimately their behavior."

Tied to all of this, of course, is the rise of , the open and decentralized identity system, and OAuth an open protocol to allow secure API authentication between application. Both of which appear to be central to most peoples' plans for the coming year.

So what were the other highlights? For me I'm really exited by and latest Yahoo! project: ; which allows you to share you location with friends, other websites or services.

You can think of Fire Eagle as a location brokerage service. Via open APIs other people can write applications that update Fire Eagle with your location so that further applications that can then use it. So for example, someone might write an application that runs on your mobile that triangulates your position based on the location of the transmitters before sending the data to Fire Eagle. You could then run an application on your phone that lets you know if your friends are near by, what restaurants are in your area or where the nearest train or tube station is.

Obviously what Fire Eagle also provides is lots of security so you can control who and what applications have access to your location data. I can't wait to see what people end up doing with Fire Eagle and I'm hoping that we can come up with some interesting applications too.

Finally, , which I have to say caught me a bit by surprise. If you've not come across it before XMPP it's a messaging and presence protocol developed by Jabber and now used by Google Talk, Jaiku and Apple's iChat amongst others (with a lot more clients on the way if last weekend was anything to go by).

XMPP is a much more efficient protocol than HTTP for two way messaging because you don't require your application to check in with the servers periodically - instead the server sends a signal via XMPP when new information is published. And there's no need to limit that communication to person to person - XMPP can also be used for essentially machine-to-machine Instant Messaging which means you have real time communication between machines.

So based on last weekend's Foo Camp it looks like XMPP, OpenID, OAuth are all going to be huge in 2008, Google's Social Graph API and related technologies (FOAF and XFN) will result in some headaches while peoples' understanding and expectations settle down but it will be worth it as we move towards a world of data portability.

A small team of elite developers, designers and project managers spent two days last week in a hardware hacking workshop. Yasser and I ran it as something to get people thinking differently, to provide inspiration, to get people away from their day job for a bit and to actually build something.

We had come up with a fairly broad brief - "build something that accompanies a radio, and allows the listener to rate the current track playing. But it should require some effort to rate, thus increasing the listener's engagement with the process" (something we'd been kicking about recently). We also had a big pile of kit (, a , a load of sensors, lights and motors, and a nearby Maplins). And we'd also managed to borrow Room 101 (!) in our building which provided us with a space where we could spread out and not disturb anyone.

We spent the first morning brainstorming ideas, eventually converging on the idea of a toy which, if you remember them, were electronic pets that required care (i.e. button-pushing) or they would die. The "DABagotchi" would behave similarly but the care consists of the user rating what they're listening to. If you don't rate the song (whether good or bad) then it loses energy, eventually dying. Similar in some ways to the which feeds on the music going through your headphones (via ).

There was then a bit of a struggle with how to make it loveable. A teddy bear with glowing eyes was deemed a bit demonic. The basic outline was to have something which displayed health (a glowing heart and some kind of movement) and something which displayed emotion (the face). We decided we would use a wireless Pocket PC to provide a screen in place of the face. In the afternoon half of the team went off to a toy shop to try to find an appropriate body for the DABagotchi. The other half went down to Maplins to look for a few bits and pieces we needed. Here's the toy they found, cute for the moment...

Nic took the bear home that evening and impressed us with his sewing skills, bringing it back the next day with the PDA being neatly velcro'd into the space that the face once occupied. And a port in the side of its head.

The following day we split up the tasks. Tim worked on the animated GIFs (!) that would provide the face graphics. Nic worked on a Rails application that would accept ratings and track the health and mood of the DABagotchi. Ant and Yasser started on the Arduino board, sensors and lights. And I worked on interfacing an Arduino with the Rails app, via . And Stephen kept us all on track with a big list of tasks.

We had a deadline of 5pm when there was a team meeting due. It was pretty tight and a number of features were dropped, most notably the bend sensor, with which we could have detected the listener bending the arm of the DABagotchi to show disapproval. So what did we end up with?

The final DABagotchi prototype lets the listener rate the track playing on the radio by squeezing its hand. If you don't do this enough then it will fall ill (its glowing heart will beat less and dim) and eventually die.

The death animation

If the listener does rate a track then this data is sent to a webserver where it is compared to their previous ratings and other peoples' ratings, causing the DABagotchi to express appropriate emotions (surprise, confusion, anger...) on its face. Not bad for 2 days work and the whole team came away pretty excited.

There’s lots of buzz around ‘Visualising Radio’ here on the 7th floor at FM&T Audio & Music towers at the moment. First, there’s DAB Slideshow, then there was Scott Mill’s ‘Radio 1 on Three’ TV show (not strictly 'visualising radio' - this is just radio-on-tv!), and finally Yasser’s post right here on Radio Labs pulled a lot of it together and got people thinking.

As I’ve said before, we like to try new things here, and nothing makes us itch more than seeing a really cool idea just sit there as a mock-up an not get any further. The one which really caught our eye was the IPTV visualisation demo. It looks great, and everyone who sees it says ‘wow, that’s cool’. So what’s stopping us from turning it into a working prototype rather than something made in Adobe AfterEffects? It turns out, not a lot. So we had a go – once again, as a 10% time project.

The idea is to take the basic now-playing data from our music radio networks, throw it at the web, and see what we can get back. We could then use this, and other ³ÉÈË¿ìÊÖ API’s to create a pretty rich visualisation console pretty much automatically. We had a quick brainstorm and decided that we’d use the excellent , the incredible , and the usual suspects , , and .

Now, before we let you take a look, some caveats….
• This is a functional data demo – there’s been no visual treatment at all. In fact, it looks pretty pants
• It can be a bit buggy
• Its mainly client-side code so you’ll need a proper browser
• We don’t use the VCS playout system in the studios overnight or some evenings, so you may not see now-playing data all the time
• There’s still some work to do to optimise the results (When we play ‘Oasis’ you can guess what kind of images we get back from Flickr….)

So given that, turn on the radio and have a play…..

Not bad for a functional prototype we think. We’ve had it running here in the office for days now and I’ve glanced at it more and more – and watched more YouTube music videos than ever before. I’ve even found out about gigs in London by my favourite bands which I didn’t know about, just by glancing at it every now and again. Thanks to for the hosting, support and general cheering on. They’re great guys.

Right, All done? Hardly. So, what next?

Well, what we want to build is a full-screenable, possibly Flash-based visualisation console. The idea being you can embed it in a webpage where it’ll work in a nice little window. But that there’s a ‘full screen’ button where (much like iPlayer) clicking it gives a larger rendered experience. We’re some way along the line of doing this now using exactly the same feeds we use in the DHTML version. We've got some rough visual designs for this and they're progressing really fast - once we've got some more stuff you show you, we'll of course post it here. But this is kinda where we're going...

Eventually, we’d like to incorporate live video streams from the studio where the web’s metadata about the current song enriches the otherwise fairly dry experience of watching a DJ speak into a mic – but we need a bit more infrastructure for that.

We’re also working on the technical infrastructure behind it. At the moment, it’s a little shonky, with the app polling an intelligently cached xml file which contains the now-playing data. Ideally we’d like to move to something like or for efficient asynchronous real-time data transfer but we need to prove the interface and audience appetite first.

So why’s this any good? Well as we learned from Yasser, Visualising Radio is all about ‘glanceability’. Its also about automation – we couldn’t do this if it was human-intensive. So this prototype shows its possible to get relevant and useful information automatically, just by knowing the artist and title of the current song, and that it really does enrich the listening experience – its incredible the amount of YouTube music videos we’ve seen out of the corner of our eyes in the last month or so.

What we need to do now is make it visually stunning (a-la Yasser’s Colin Murray IPTV prototype) and work on the data to make a truly compelling offering.

Before I go, just a quick nod to the other people who are doing similar things with either our data or their own.
• is taking our feeds and helping you buy that music on Amazon, and pulling in similar data to us from Last.fm.
• have got a similar idea of taking an artist, throwing it at the web and seeing what comes back – often some really cool stuff.
• do a mashup with your Last.fm now-playing data and again crawl the web for useful nuggets of data to enrich your listening experience.
• Finally takes the slightly different approach of creating a psudo music TV channel based on the live Radio 1, Radio 2 or 6 Music now-playing data. The idea is that you can watch this independently of listening to the radio, and you’ll get all the music Radio 1, say, are playing but with added pictures.

Nice thoughts on our Coverflow-style podcast browser

"Feinstein told investigators that he was "very unhappy" about the changes to his playlist"

Is XMPP the future for cloud services? It's more efficient than http polling.

Aggregated music info, integrated with FoxyTunes browser-based music player.

And finally, some conferences that look interesting...

Hackday for mobile, April 4-5 2008 in London.

UK-based -style conference at the Sage, Gateshead in May

I'm off to next week, might see you there...