What the numbers suggest: four Peel the Apple tracks
This post is an attempt to read what audio features suggest,
not about quality, but about roles inside a group.
Using tempo, valence, energy, and danceability,
I looked at how four Peel the Apple tracks function differently.
Related:
→ Listening to Peel the Apple as data
This post provides minimal examples of how track data and audio features
are collected and compared for music-as-data.
--
Getting track data (curl)
Search artist
> curl -s "https://api.reccobeats.com/v1/artist/search?searchText=Peel%20the%20Apple&page=0&size=10"
Get artist tracks
> curl -s "https://api.reccobeats.com/v1/artist/{ARTIST_ID}/track"
Get audio features for a track
> curl -s "https://api.reccobeats.com/v1/track/{TRACK_ID}/audio-features"
{ARTIST_ID} and {TRACK_ID} are obtained from the search results.
I've created music-as-data because I really hated trying to write about sins, freqs etc all the time in order to produce a single note. Also, it was very difficult to add abstraction and extend AND having fun all at the same time. I think that (music [as data]) is disruptive in how we think and interact/transform music. Or maybe not.
So, one of the main advantages of having music as data as code, is that we can have our music commited to version control systems. So, what would happen if we form bands that are only using code to create music, and can fork, revert and exchange music snippets? Wouldn't that be awesome? Well, who knows? It surely sound interesting.
This is a call to wannabe rockstars: Get music-as-data, create a repository in github, get your friends together and (why not?) form the first EmacsBand. Who knows? You might even become a GuitarHero game. Or maybe not.