The second thing I did this week was revisiting the timer system.  One of the main problems I’ll have to face is accurately measuring the user’s position in their song.  If the website is going to make a transition at a given timestamp, it first needs to know where the user is in their song (to know if they’re at the timestamp).  The best way to do this would be to place a webhook (event listener) so that when Spotify detects that the user has reached the target timestamp, they alert me and I can make the transition.  Unfortunately webhooks aren’t supported by the Spotify API.  The second best option is to open a longer-term connection with the Spotify servers and listen on maximum intervals for changes.  By waiting the longest possible time on each request, I can maximize my listening area while minimizing the resources required.  This technique is called long-polling, and yet again, Spotify doesn’t support it.  That leaves me with the third best option, keeping my own timer locally.  I do this by making one API call when the player starts to get a current timestamp then I can synchronize a local clock to infer the user’s current position.  I can also periodically resync this local timer with more API calls to make sure the user isn’t fast-forwarding or rewinding their music.

To do this, every millisecond needs to be tracked and accounted for, or else the local timer will become desynced with the user’s actual player and the jump won’t be performed at the correct time.  The first step of keeping accurate time is (obviously) the timer itself.  I need a timer that has sub-millisecond accuracy and can adjust itself based on natural drift that all computer programs experience.  On every iteration, the timer needs to calculate the drift (the time taken to perform functions) since its last step and subtract that drift from the interval (expected time between iterations).  

In the second screenshot, you can see the phrase ‘it ran!’ being printed at the beginning of every iteration along with the drift since the last iteration.  This drift is then fed into the interval to adjust for the next iteration, creating a self-adjusting timer.

The third screenshot is another screenshot of the timer, but instead of logging the drift on every iteration, we log the unix epoch time (time in ms since 00:00:00 UTC January 1, 1970) so we can see the timer in action.  This timer was set to fire the ‘it ran!’ code every second.  You can see how every iteration is performed exactly 1000ms (1 second) after the last with sub-millisecond error, meaning the timer works as intended.

Once I have the vectors, I’m ready to compare.  The first solution that came to mind was the K-means clustering algorithm.  K-means clustering is a way of grouping similar things together based on their characteristics.  It starts by guessing where the centers of the groups might be, then assigns each thing to the group with the nearest center, and repeats until the groups don't change much anymore.  After the clustering was complete, I’d be able to find the current song and build out the playlist starting in that cluster.

The issues with this technique begin when we leave that first cluster.  While clustering is great at showing me a handful of similar vectors given an input vector, it’s not as good at creating a larger picture.  Knowing which cluster should follow the current song’s cluster adds another layer of complexity and doesn’t even guarantee that the playlist will retain ‘flow’.

A better way to create flow would be to start with the current song and compare it to every other vector in the queue, then pick out the best match and put it after the first song.  I could then repeat this process recursively for the newly shuffled song (and the songs after that) until the queue has been fully organized.  This guarantees that every song will be followed by its best match and that the songs flow out of the first track.  

The metric I chose to compare the vectors is cosine similarity.  Cosine similarity is a way to measure how similar two vectors are based on the cosine of the angle between them in a multi-dimensional space.  I chose it because it’s a norm I’m familiar with.  Unfortunately, cosine similarity is generally less accurate on lower dimension vectors (mine are only 12 dimensions), because the angle between two vectors becomes less distinctive as the number of dimensions decreases.  Because of this, I’ll probably experiment with some others (maybe 2-norm?) and try to find the most accurate.  But until then, cosine similarity will have to do.

This week I began the process of changing my beat-finding algorithm.  This is the way that my program decides which milliseconds to jump and land at.  My original algorithm was primarily a placeholder, so not much thought went into it.  It was essentially just comparing two track statistics that Spotify makes available in their api - timbre and pitch.  Timbre can be described as the ‘quality’ of a sound.  Timbre is how different instruments playing the same pitch still sound distinct.  A cello and a piano both playing C are pretty easy to tell apart.  Pitch is the way of classifying frequencies that most people are familiar with (example of  A, B, C, C#).  My old algorithm would take two songs, measure their pitch and timbre, then compare the results using Euclidean distance (square root of sum of squares).  This week, I switched that process up a bit.