Client
Philips Sound
Headphones
Tables
To gain Philips headphones a presence in the locations that young, 'cool' people hang out. A series of tables were produced and distributed to bars across London, each one with a bespoke design giving a nod to the character and personality of the neighbourhood.
Beyond just being a table with a beautiful top, each one was built with a headphone jack contained. Plugging in your headphones, automatically triggered a playlist to begin playing.
It wasn't only the tabletops that were designed to reflect the character of the area. The sound of the place was at the core of the tables.
The playlist that a user heard when they plugged in their headphones, was a dynamic snapshot of what people in that area were listening to at that moment in time. Nuanced with the variations in music that occur throughout a day, and across the week.
Geolocated tweets, containing the 'nowplaying' hashtag, were used to determine what people were listening to in the vicinity close to where the tables were positioned.
These then had to be processed to determine the artist, track title and version where specified.
Obtaining the tweets containing what people are playing is the easy part, making sense of them is then required.
Each tweet needed to be processed to determine any musical information from them, such as a clean artist/title/version, that can be used to provide any kind of service. A rough outline of the process follows:
The tables can be managed, and basic stats on their usage viewed on a custom privately distributed Spotify application. The app looks to update the playlist with any changes on a set interval.
It compares the hash of the playlist at the current moment in time, with that of the stored playlist. If they are the same, then it resets, and awaits updating again. If they are different, then it completely updates the Spotify playlist and stores the newly generated hash. Each 'listen' of the tables, makes a small request to the server, which logs the ID of the table and the itme for generating simple listen history stats.
A RaspberryPi is used inside the tables, to handle audio playback when required, and consume the relevant playlist.
The RaspberryPi queries against the web service every time it becomes idle. The web service returns the hash of the current playlist, along with a Spotify playlist URI that contains all of the tracks for that list.
If the hash is different to the one that the Pi is currently aware of, it queries the Spotify playlist URI to ensure it resolves, and on success, stores it's new hash reference and playlist for use next time a user plugs in their headphones.
All communication with the Spotify API for requesting and streaming of tracks is done utilizing pyspotify.
My role
On this project, I built the entire server side implementation in NodeJS/Mongo/Express, with integrations to LastFM, Twitter and Spotify's APIs. Along with the Spotify application for managing and creating the playlists for each of the tables, and the API which both the Raspberry Pi and the admin application consume.
Following this, I then worked with Lorenzo Spadoni on the Raspberry Pi side of things, and using pyspotify to handle connection to and streaming of tracks from Spotify when sent a new playlist.