Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

random: Return random tracks by time constraint #2305

Closed
bearcatsandor opened this issue Dec 5, 2016 · 9 comments
Closed

random: Return random tracks by time constraint #2305

bearcatsandor opened this issue Dec 5, 2016 · 9 comments
Labels
feature features we would like to implement

Comments

@bearcatsandor
Copy link

It would be really cool to have a random by time function. Such that when you had 30 minutes before you raced out the door, you could give the random command a time and it would pick tracks that would fit within that time constraint.

Then the resulting tracks could be piped to other commands, and utilized for the "play" command as well.

One could do:

beet random -t 37
to return 37 minutes of random tracks

beet random -t 45 "Metallica"
to return 40 minutes of random Metallica

beet random -t 120 title:cats
to return 2 hours of random tracks with the word "cats" in the title.

If one didn't have 2 hours worth of tracks with the word "cats" in them, it would just return as much as it can.

Random could be set up to return a defined number of tracks as well, but that's another Issue.

@sampsyo sampsyo changed the title Suggestion: Return random tracks by time constraint random: Return random tracks by time constraint Dec 5, 2016
@sampsyo sampsyo added the feature features we would like to implement label Dec 5, 2016
@diomekes
Copy link

I've made changes to the random plugin to implement this. I won't open a pull request because it has other changes that I made for #2304, but here's a pastebin of it:

https://ptpb.pw/tJ4N

@bearcatsandor
Copy link
Author

That looks awesome and better than i'd dreamed! Thank you!!!

@sampsyo
Copy link
Member

sampsyo commented Dec 12, 2016

Nice work, @diomekes! This looks awesome. I'd love to merge the new feature separately if you're amenable to splitting up the patches.

@diomekes
Copy link

diomekes commented Dec 12, 2016

Yes, I can do that. I'll add the code to the current random plugin (which does not define several functions, just the main one, so I'll add the code under that function).

Can I run the tests that github runs on pull-requests on my end (either off-line or through github) so I can fix small issues before requesting a pull?

Also, do you want me to add the extra documentation or do you usually do that?

@sampsyo
Copy link
Member

sampsyo commented Dec 12, 2016

Yes, awesome! Thank you!

Here are some tips on running tests: https://github.com/beetbox/beets/wiki/Testing

And yes, please do add some docs (even just a draft is good).

@diomekes
Copy link

OK, I'm almost done with the plugin code. Quick question: Should I make -e and -t mutually exclusive or should I add a if opts.time into the if opts.equal_chance? Here are pastebins to see the two options:
https://ptpb.pw/_238
https://ptpb.pw/Z09i

@sampsyo
Copy link
Member

sampsyo commented Dec 13, 2016

Huh—interesting question. Can you explain intuitively how things work if -e and -t are used together?

@diomekes
Copy link

I'll try, if I understand -e correctly.

-e chooses a song by first making a list of artists and choosing a random artist from that list (instead of a list of songs, and choosing a random song). That way, it doesn't matter how many songs from each artist you have, all artists are treated equal and once it chooses all the songs from one artist, that artist is deleted from the list.

With -n, it does that N times.

With -t, it does it until it reaches -t minutes, or more exact it stops if it can't find any song that would keep it under the minutes.

I like to use -e because it seems more random to me than without it, but the code looks kludgier to me (once again, I'm new at this, so there is a more elegant way I'm sure).

@sampsyo
Copy link
Member

sampsyo commented Dec 15, 2016

OK, thank you for explaining!

It sounds like the combination of the two would be good to keep. Feel free to open the PR as is; maybe we can sort out a simpler version of the code afterward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature features we would like to implement
Projects
None yet
Development

No branches or pull requests

3 participants