Allow play plugin to choose random albums

[duailibe]

So, sometimes I don't feel like choosing what I want to listen and just want something random. Since we already have the great random plugin, I don't think duplicating features is the best way to go here.

I'm looking for some suggestions :-)

[sampsyo]

One strategy—not sure whether it would work—would be to have the random plugin provide a query instead of a command. You would be able to say something like:

beet ls something random:5

and beets would pick 5 of the songs matching something. Then randomness could be used with anything based on queries, including the play plugin.

[duailibe]

That's a great idea. I'll start hacking on it and see what I can do with it.

[duailibe]

So it seems there's currently no easy way to provide a query based on a "field", like random:5 in the example you give, but instead only using a prefix. Besides that, there'd be no easy way for this query to track the current state (e.g., how many tracks it matched already).

Does this sound correct or am I missing something?

[sampsyo]

Yes, you've got this right on both counts.

Here are two ideas:

• Use a "pseudo-field" called random that uses a special RandomQuery as the query for its type. This would abuse the current system for providing type-specific queries for certain fields (e.g., fields that are integers or floats use NumericQuery). Not sure if that's the cleanest idea, though—we could certainly add special support for pseudo-fields if the current infrastructure is insufficient.
• And yes, a random query will need some way to choose a subset of all other matches. I'm not sure how to best design this, but one approach would be to get the number of matches for a query and choose the indices of the tracks to return. Then the random part of the query could "match" only at those times (i.e., it could keep an internal counter). It seems like we'll need additional support to make this work.

Overall, we should think of what the best UI would be for this feature (is random:5 the right interface? I don't currently have a better idea…) and hack until it's possible. :smiley:

[duailibe]

Thanks for the suggestions. I'm not that sure if we should hack these things, though. I do like the random:5 interface (I also can't think of a better one) but this is indeed abusing the field querying system. Do you think we'd have real use cases for "pseudo-fields" ? If so, I agree it would be a nice addition, but I'm not comfortable hacking that much just for this feature :-)

A simpler solution would be to simply implement the random feature in the play plugin and we'd be done with it. I prefer the idea of interoperability between plugins, but I the simplest solution here seems to be best. I'm curious about your opinion.

[sampsyo]

Yeah, it could be that this should be a longer-term thing. Feel free to add the random selection to play itself; we can go back later and figure out the general solution if we come up with something good.

On that note, it should actually now be relatively easy to add pseudo-fields. In #647, I'm adding a way for plugins, etc., to define types for flexible and computed fields. It should be possible to use this to specify a query type for a field that doesn't actually exist—just provide a Query subclass that doesn't inherit from FieldQuery and you should be good to go (I think).

[jubalh]

I am using:

beet random -n5 -p | xargs -d '\n' mpv

for similar purposes :-)

[clach04]

• https://github.com/beetbox/beets/issues/795#issuecomment-177663532 - very neat!

I'm using:

beet play $(beet random -n 1 -f '$title $artist')

This can/will generate more than one random track if there are dupes (or remixes).

Also:

beet play "$(beet random -n 1 -p)"  # only works with one track, ensure handle spaces in path correctly