Feature request: Create smart playlists based on beatsPerMinute (BPM)

10 views
Skip to first unread message

jbo...@gmail.com

unread,
Nov 27, 2017, 4:22:58 PM11/27/17
to Autoplaylists for Google Music
First off, it was a bummer that I had to install the extension just to find out what fields I could sort by. Including a list or even just a screenshot of the open dropdown in the Play store or Github  would have settled the matter for me without having to install it.

More importantly, what I'm looking for is a way to make smart playlists based on BPM. I see from looking at the gmusicapi usage docs that `beatsPerMinue` is returned by `Mobileclient.get_all_songs` alongside all of the other variables that the Autoplaylists extension keys off of. I'm guessing the data isn't the best (your example just lists '0'), but it would still be nice to be able to give it a try.

Simon Weber

unread,
Nov 27, 2017, 8:01:22 PM11/27/17
to Autoplaylists for Google Music
Ah, good idea. I'll probably add a list to the wiki and link it from the project site.

I'll take a look at BPM when I have a chance. Autoplaylists uses one of the old jsproto interfaces since it provides more fields, but figuring out which is which can be hit and miss.

jbo...@gmail.com

unread,
Nov 28, 2017, 9:07:23 AM11/28/17
to Autoplaylists for Google Music
Thanks!

Simon Weber

unread,
Nov 29, 2017, 7:19:33 PM11/29/17
to Autoplaylists for Google Music
I went the lazy route and had the wiki link to the code. The project site needs an overhaul anyway; when I get to that I'll see if I can do something fancy like auto-generate the list based on the code. Hopefully this is an improvement in the meantime!

I also took a look at bpm and have bad news: the data doesn't seem to be available to Google's web interface, which means it's not pulled in by Autoplaylists. Here's what I did:
  • used gmusicapi to find all songs in my library with a non-zero bpm (only 70 of ~10k)
  • picked one with a unique bpm (142, in my case)
  • pulled that song's jsproto to match the field to the value in the last step
To my surprise, I didn't see 142 in the jsproto at all. Here's the data in case you want to take a second look. Until now I had thought the web client got everything Google had while the mobile clients got a strict subset; this is the first counter example I'm aware of.

Despite this it's possible for the extension to work around it and pull bpm from the mobile apis. That'd be a significant hassle, though, and the quality of the data doesn't make it seem worth it.
Reply all
Reply to author
Forward
0 new messages