Team B3: Music Mirror

As mentioned last week, I spent the majority of this week working on the ML module. The main goal was to be able to generate song recommendations from a generated seed containing info about a song. I was able to build a Java module that communicates with the proper Spotify endpoints to do exactly this. Below is an example of the generated song recommendations for an input seed that represents: artist = The Beatles, song = Help!, genre = rock. This is the full output

As we can see it works amazingly which is very cool to see. The generated songs from such a simple query are already very relevant to the input song. This shows very promising results for how much we will be able to fine tune our results with much more complex input seeds based on the listening session data we obtain. The next steps for this will be to create a cleaner class for building seeds to input into the model.

In addition to this coding, I helped my team prepare for the design presentation by working on the slides and contributing some important things. Mainly, I created the block diagram which took a lot of thought and effort.

As we can see, our system design is really coming together which is fantastic to see.

In terms of schedule, I would say that we did a great job in catching up on schedule this week and getting some important things done. Once we are done with the design presentation, we will be able to really buckle down and grind out a lot of the critical models for the design.

Next week, I plan to continue with the ML development, and will hope to integrate communication between the two pi’s because this will be important for the actual lifecycle of adding a recommended song to the queue.

This week, I focused a bit more on the Spotify web player and authorization protocol rather than the ML model. The architecture of our server interactions with Spotify were more complex than initially expected so I had to come up with unique solutions that would work on a RasPi. The resulting solution was as followings: launching a NanoHTTPD server to send and receive requests, and then using Selenium WebDriver to authorize with the Spotify authentication endpoint. The tricky part here is that typically with Spotify web apps, there will be multiple users logging into your app with their own Spotify credentials via a web browser. But, we want to house this infrastructure in a Pi, with no graphic interface for the login credentials, since we will only be using a single Spotify account for the system. Thus, I needed to use web driver to automatically interact with the redirect URI that Spotify responds to an auth request with. This involves entering credentials, logging in, and then grabbing the session params after the successful login to retrieve the Authorization code that will be used to make future Spotify API requests that need user scoping. Below you can see this in action as we start the app:

Then, a Chrome WebDriver instance is launched, directed to the Spotify login page.

The credentials are then automatically entered. For this example, I am using my account but in the future we will have a premium account solely for the Music Mirror system.

And finally, the driver is automatically closed once the authorization code has been received.

In addition to this, I worked on more solution approach work to prepare for this week’s presentation

We are mostly on schedule, but I am a bit behind on the ML module development as this authorization solution took longer than expected to devise. However, we are on track in all other areas and should be making great progress next week.

Speaking of, I plan to now use this working auth infra to build the ML rec model wrapper that will communicate with our user’s input and the Spotify API to create song recs to add to the system queue. I also plan to solidify any other solution design decisions in terms of the ML modules for the system.

• This week, I spent a lot of time on the proposal presentation. I helped to translate our problem statement into a set of plausible and quantitative user requirements, along with Matt and Thomas. I translated our research document for the proposal into a visual set of slides which matched our team’s brand and vision. Further, I worked on the Music Mirror system diagram, which required a lot of research and thought into how we would actually structure our solution approach. Attached below is the mentioned diagram:

• Further, I was the presenter for this proposal presentation, so I spent a lot of time preparing the actual speaking component of the presentation. This included brainstorming a captivating introduction and conclusion, as well as many rehearsal runs.
• On the more technical side, I spent time planning out our recommendation system architecture, which revolved around a collaborative-filtering design. Further, I found good datasets which we could use to train and validate our model, including the last.fm dataset (http://millionsongdataset.com/lastfm/) which is a great candidate for our purposes. Lastly, I began to get familiar with the Spotify API structure.
• We are on schedule with the project so far. Next week, however, there are quite a few things we aim to complete. Especially, we will begin building our project codebase starting with the interactions with the Spotify API
• Next week, I plan to make a final decision about how to proceed with the ML model versus writing a wrapper system around the Spotify API recommendation features. With that, I will have functional preliminary progress on the recommendation portion of our product. Further, I’d like to test around with the Spotify API music player to figure out how exactly we will be transmitting song resources to the Bluetooth speaker system. With that being said, we will work to clearly define our system’s solution design in preparation for the design presentation and document.