I had planned on releasing Part 4 of the iGoverness Project Visions series, but haven’t really been able to get myself into the writing mood this morning.
So, instead I’m going to introduce another series of Project Visions, this time about the Gravity Randomization System.
Gravity Randomization System (or GRS) is a system for randomization of playlists, based on universal physics concepts. Briefly, an object is assigned a mass according to different deciding factors, and the randomization is involved in the attraction of the acceleration of the gravity that mass creates.
A Quick Example
Let’s take for example a music playlist. Any song on the playlist has a list of attributes that define the interactions it has with the other songs on the playlist:
- Song Title
- Track Number
- Year of Release
All of these attributes are inherent in each song of the list. While each of these is important in the grand scheme of the user’s library, not all of them will be important to the base concept of the GRS. More advanced features will include the extra attributes, but we’ll stick to the basics in this example.
Think of a song as if it were a heavenly body in a solar system. Where the different levels of the system come in is for later discussion. Let’s focus on the idea that the center of the system is the artist. The artist is akin to a star in a solar system. It has the greatest mass of any of the objects in the solar system, and is the object in which all others orbit.
With this first diagram, we see the Artist System (analogous to a Solar System). The artist is the star of the system, which holds the greatest mass. The mass of an artist is created through number of times played and user rating.
As you can see, each Album orbits the Artist according to the release date of the album. The orbit length (or the length the year of an Album orbit) is determined by the amount of time between album releases, with the first album being a pre-set distance from the artist.
Now, this is configurable, because sometimes certain albums from one artist can be more desirable than others. So, a system for ordering the albums by preference will be included, allowing the user to customize to his liking.
The second diagram here shows the album system.
Each album is orbited by tracks that are arranged by number as default. The user will have the ability to change the orbits according to preference. The mass of the album and tracks are determined again by number of plays, as well as factoring in user ratings.
The default setting does not allow for drift according to mass, and everything in the system will be according to pre-set distance and orbit variables, generated from the information in the ID3 tags.
A second setting could allow for drift, where album systems with larger masses drift closer to the artist according to play counts and user rating, and therefore changing the probability that one track will be played.
Now, we need to quickly deal with the way artists are arranged in space. The default model will have artists grouped into ‘galaxies’ by genre according to the information provided in the tracks’ tags. Each galaxy will be populated only by artists, albums and tracks that are specifically flagged as being part of that genre.
How are the tracks in the universe navigated?
When one track ends, or the user passes a ‘next’ event, the amount of time played for the song will be added to its mass. Say a track is 4:00, and only 3:52 of the track was played before the user passed a ‘next’ event. 97% of one mass unit will be added to the track, and an escape velocity will be calculated accordingly.
Depending on user settings, the launch from the last played track will occur with a derived velocity greater than the escape velocity of said track. This allows no direct succession repeats. The navigator will leave the track from a randomized point on the sphere of the track, and head out at the derived velocity.
If the user wants to have tracks in one album system more likely to be repeated, the derived velocity will be lower, insuring a better chance of a related track to be played.
Interesting theory, but how could this be implemented?
Well, I’m not physicist by any stretch of the imagination, nor do I understand how calculations like this would be created. I am just putting the idea out there, in hopes that someone sees it and doesn’t think it’s complete garbage.
Technically speaking, this wouldn’t have to be its own stand-alone player, it could easily be a plug-in for some other player.
There is a good bit of mathematics involved here, so I’m not sure how performance would be assessed. Other extraneous factors such as dark matter, solar winds, and interstellar medium would not have to be taken into account, so it may be significantly simpler than doing these calculations for the real universe. With the abundance of high-end computer systems in the consumer market nowadays, I would think that dual core/many Gb RAM systems should be able to handle these calculations in a reasonable amount of time.