Ferit Albukrek

falbukrek@yahoo.com

CSCI E-64

Final Project

Project Title

OpenEar – A Listening Plan Builder

 

Project Members

Ferit Albukrek (falbukrek@yahoo.com)

 

Motivating Questions

Many online music services offer the capability to find artists that are similar to a given artist.  The purpose of this project is find artists that are not similar, yet the listener might still like.  Specific question to answer is: ÒWhat artists should I try that might expand my listening repertoire?Ó

 

The visualization is of specific interest for:

á      People who are looking buy music gifts for music buffs. 

á      People who are interested in exploring new genres.

 

The primary motivations for this application:

á      Search engines are very sophisticated, but they only allow the user to find one artist of interest, or artists that are mentioned in that one artistÕs description or bio.

á      Using the Òwisdom of the crowdsÓ has been leveraged to make purchasing suggestions.   However, these suggestions tend to offer Òmore of the sameÓ as opposed to really interesting and unique combinations.  This application will deliberately filter out the Òmore of the sameÓ suggestions and give the user the opportunity to really broaden his/her musical taste.

 

I chose these questions because I am a frequent user of internet radio services such as Pandora.  I find that the stations created by these types of services, when seeded by a small number of artists, offer very little diversity their recommendations.

How to Run OpenEar

OpenEar is a Processing based java application. It requires java 1.5 or later to be installed on your computer. A display of 1024x768 is a minimum -- the larger, the better. Please follow the steps below:

  1. Download the OpenEar.zip file.
  2. Unzip it in a directory you would like to run from.
  3. Go into the OpenEar directory that is created by the unzip.
  4. Open (double-click) the OpenEar.jar file.
  5. Optionally, you can start open ear by typing 'java -jar OpenEar.jar' at the command line from the OpenEar directory.

Sources of Data

All the data is collected in real-time using the Audioscribbler API.  Here are the specific types of call that were used in this application:

á      Artist.getInfo(name, apiKey): This call is heavily used to retrieve images and textual description for each artist.  It is fairly expensive (slow) call to make on a one-by-one basis.  So results are cached in memory to improve performance over time.

á      Artist.getSimilar(name, apiKey): This call retrieves a list of Artist objects that are similar to the one provided in the parameter.  By default the call will retrieve up to 100 artists.  It is important to note that Artist objects on this list are skeletal in that they contain minimal information.  It is necessary to call Artist.getInfo() in order to get a fully populated Artist object.

á      Artist.getTopFans(name, apiKey): Retrieves a list of User objects who are the top fans of a given artist.

á      User.getTopArtists(name, apiKey): Retrieves the list of top artists for a given user.  Similar to the Artist.getSimilar() call the Artist objects returned are skeletal.

 

The application retrieves all the necessary data using these four types of API calls.  Specifically the algorithm is as follows:

 

1.     Let x = a given seed artist. 

2.     Create a set S of similar artists using Artist.getSimilar(x).

3.     Create a set F of top fans using Artist.getTopFans(x).

4.     Create a set A of top artists by calling User.getTopArtists() for each user.

5.     Create a recommendation set R of top dissimilar artists by subtracting S from A.

6.     Analyze set R to rank artists by number of occurrence.

 

Visualization Design

 

The visualization consists of two distinct screens.  Below is a typical screenshot of its operation.  Each of the design elements will be described in detail below

 

 

A.     Startup Screen: Simplicity was the primary design objective for this screen.  It offers a description of the program and invites the user to start by entering the name of his favorite artist.  As required by last.fmÕs terms of service, credit is given to them for the data and their logo is prominently displayed as well.

 

 

B.     Main Screen:  This screen is the body of the application.

 

a.     Data Retrieval Progression: The application retrieves large quantities of data from last.fm.  The download can seem slow, especially during the first time use when the userÕs cache is empty.  To give more visual feedback to the user, a progress bar is visualized and fills up as the task completes.  The underlying visualization continuously updates itself to show how the recommendations change as more data comes in.  Below is an example of two screenshots illustrating how the visualization changes over time:

 

 

 

b.     Recommendations Panel:  This panel visualizes the ranked recommendations.  A tile with the name and a small photo represents each artist.  The border color of each tile encodes the ranking within the entire result set.   The rank colors were selected using ColorBrewer  for a three class sequential scheme.  The charcoal background allows the tiles to pop out and the black heading clearly delineates the area from other areas of the screen. 

 

 

The panel only displays the top 20 artists in the result set.  I chose to not waste precious space on a scrollbar, because the lower ranking results tend to be very noisy (very large number of artists with a score of one or two) and are not particularly useful to the tasks supported by this application.

 

c.      Artist Tile:  The artist tile is designed with minimalism in mind.  The design objective was to make them small so that we could utilize the limited real estate more effectively.  Embedding each photo in a black frame reduces the competition between the images and unifies each artist into the same umbrella.  A black background is flattering to most artistic headshots and album art.

 

 

Because the images supplied by last.fm do not have consistent size and aspect ratio, each photo is resized at runtime to fit into the tile without distortion.

 

d.     Artist in Focus: This area offers more detailed information about the artist along with a larger photo.  A clickable last.fm link allows the user to visit the webpage where music can be sampled.  The artist displayed in this zone is linked to whatever artist tile is selected elsewhere in the visualization.

 

 

e.     Listening Plan Panel: This area progressively constructs a tree of artists as the user drags and drops in from the recommendation list.  Each added artist is linked to its corresponding seed artist as a parent.  The edges inherit the color of the rank of the child when it had been found in a result set.

 

The current seed artistÕs tile is indicated with a blue border.  This means any artists dropped into the panel will become children of the seed artist.

 

The tree representation and the layout are supported by the Java Universal Network/Graph Framework (JUNG).  While the library also offers rendering capabilities they are not compatible with ProcessingÕs framework.  So I only used the data structures and the positioning algorithms from JUNG.  I wrote the drawing procedures as a part of this project.

 

 

Each draw cycle updates the positions of the nodes.  Because of the constrained space nodes can begin to ÒjitterÓ when there are a lot of them present.  The JUNG libraryÕs SpringLayout algorithm at this time does not support a way to constrain the number of time steps allowed to reach stability.

 

While being able to drag the nodes around is one of the most common interactive features of any physics based graph layout visualization, I ran into several difficulties with responsiveness to mouse clicks.  Because the interaction design uses clicks and double-clicks for selecting and changing the seed artist respectively, allowing dragging of items in this panel interfered with click based actions.  Ability to drag the nodes around, while not specifically important to the task of this visualization, can be very engaging and fun for the user.  This is left as a future enhancement to the project.

 

f.      Reseeding the Recommendation Panel:  Double-clicking on any artist in the Listening Plan will trigger a new round of data retrieval similar to the first time.  A progress bar is overlaid on top of the graph while information is retrieved.

 

 

g.     Selection of an Artist: Clicking on an artist tile will select it.  This will in turn modify the Artist in Focus area.  The selected artist is indicated with a green marker.  The shape of the marker is unobtrusive, but the green color makes it easily noticeable.

 

 

Pressing ÔDELETEÕ or ÔBACKSPACEÕ while a Listening Plan tile is selected will remove it from the plan, provided that it is a leaf node, not the root or the seed artist.  This limitation was imposed to avoid accidental deletions of large chunks of the trees, since an Undo feature is not available at this time.

 

h.     Help Panel:  Hitting ÔHÕ on the keyboard will bring up a help panel with an explanation of how to use the application.

 

 

 

Instructions on Usage

Instructions on how to use the application are provided via the help feature.   Here is a summary:

á      Click to select an artist.  The selected artist is indicated with a green marker.

á      Additional details about the selected artist can be seen in the top right corner.

á      Drag and drop recommended artists into the upper panel to add them to your plan.

á      The artist currently seeding the recommendations is indicated with a blue border.

á      Double click an artist in your listening plan to retrieve recommendations based on that artist.

á      Hit 'DELETE' or 'BACKSPACE' to remove a selected artist from your plan.

á      An artist that has children or is currently seeding recommendations cannot be removed.

 

Insights into the Data

The visualization is quite successful in unearthing interesting music selections with a given seed artist.  Here are a few observations on the performance of the algorithm:

á      The recommendations that cross genre-boundaries tend to be much more useful and interesting for the task of expanding oneÕs listening repertoire.

á      The chart toppers such as Coldplay, Radiohead and the Beatles tend to be returned in the results no matter what the seed artist is.  This is because they are on so many peopleÕs top artists lists.  This means the real gems and the good-finds are probably more often in the middle-third rank.

á      The more niche the seed is, the more useful are the results.  For example The Swingle Singers is a group known for their jazz interpretations of classical music.   One of the results returned when they are used as a seed is ÒWeird AlÓ Yankovitch known for his parodies of contemporary radio hits.  The link between the two artists is their re-interpretive approach.   And neither shows the other as a similar artist.  It is this type of lateral connection OpenEar is intended to make.

á      Last.fmÕs data is social network based.  It is not meant to be factual – they donÕt even have a formal genre taxonomy.  This means all the data is biased by the demographics of their customers who are technology savvy music lovers who listen to internet based radio.

 

Suggested Improvements

There are several improvements that can be proposed for future iterations.

á      The algorithm could be adjusted to discount chart-toppers in order to improve the usefulness of the results.

á      A save function for the listening plan and a way to record the userÕs feedback on artists over time.

á      Ability to Ôstart overÕ – currently the application needs to be restarted for a fresh listening plan.

á      Ability to stream music from within the application.  Unfortunately, this can only be done for paying customers of last.fm as the API licensing does not allow streaming for anonymous users.

á      Ability to ÔscrobbleÕ an entire listening plan.  Scrobbling is the process of adding artists to a userÕs library on last.fm.  This requires a user account.

á      Ability to move tiles around in the Listening Plan zone.

á      Using smaller tiles in the Listening Plan zone in order to accommodate more artists.  Or alternatively, adding scrollbars to the zone to support a larger canvas.

 

 

Technical Notes

OpenEar is provided as an executable java application.  It requires Java 1.5 or later and has been developed and tested on a Mac OS computer.  Please see the README.txt file for instructions on how to run it.

 

Credits

The following external libraries were used in this project.

á      controlP5: For the implementation of the text box in the opening screen.  controlP5 offers a library of GUI controls that are specifically optimized for display in processing projects.

á      JUNG (Java Universal Network/Graph Framework): For maintaining the tree/graph data structure and the assignments of positions to nodes using the SpringLayout algorithm.  The JUNG framework offers several other facilities including the rendering of graphs and algorithms for tree/graph analysis.

á      org.clapper.util: To strip out HTML tags from artist descriptions.  Clapper.util is collection Java utility libraries.

á      Last.fm Java API Bindings: Used for all last.fm calls.  This library is a Java wrapper around the HTTP based API for last.fm queries.

á      Note: Some of these libraries require additional third party dependencies.  For a complete listing, please visit the home page for each library listed above.

 

Final Thoughts on the Project

á      I enjoyed working on this project because it involved integrating a number of external tools and libraries to make it work.  I found myself having to rapidly learn each framework, but only choose the specific pieces I needed.

á      Transitioning from ProcessingÕs IDE to a Java IDE helped me better understand how Processing is architected.  It was nice to have the benefits of a debugger for such a complex project.  ProcessingÕs IDE hides a lot of the gory details of JavaÕs class structure which can be a curse and a benefit.

á      In general I found Processing to be a great architectural match for rendering the objects in the main screen.  Implementing GUI elements such as text boxes, mouse-clicks and placement of text on the screen were extremely tedious and low level however.

á      I found working with limited screen real-estate challenging.  This is problem was most acute in trying decide on a tree layout algorithm.  The JUNGÕs SpringLayout was the only one that had provisions for constrained space, but it came with the visual ÒinstabilityÓ when the screen got crowded.

á      I quite liked the idea of my data source being Òlive.Ó  It added a certain level of dynamism to the project.