Each element, unless shorthand, should be in the “prefix:value:suffix” style.
That said, lets see how to express AND and OR in this case. Lets assume for a moment, I wanted to have a radio that had two separate tag streams and one uses AND the other OR. Your suggested !AND notation gets a bit tricky here – does it refer to the following element, or all elements that follow it, until a !OR is seen?
One way to make it unambiguous is to directly attach the operation to the element. This could work:
That was my feeling as well. OR by default brings in too many tracks and dilutes the whole playlist – but that might be because I intuitively understand the underlying data and thus am not a good end user.
Yep. In this context, there is no difference between tag or genre. Genre MBIDs can be specified with the genre: term. And my proposed way to express this is as follows:
AND should be the default usage. But as soon as any option it’s documented, it’s fine.
I would suggest to allow complex queries, like…
#trip-hop AND (#Electronic OR #Chill)
As far as I have understood your replies, this should be equal to this (?):
‘tag:(trip-hop):and tag:(Electronic Chill):or’
But not sure how it would work as soon as you add more levels. Also support for NOT or negating an operator would be required.
Now, not sure if all that can be translate to Lucene at all. Queries like that are present on mp3Tag, foobar2000, musicbee, beets, etc. In the long term, they would allow to greatly enhance playlist creation.
I would add another operator, which would greatly simplify usage for complex queries. Combinatory Or. i.e. check at least any X tags are matched.
tag:(Electronic Chill Downtempo):orX
tag:(Electronic Chill Downtempo):or2
Which would be equal to
tag:(Electronic Chill) OR tag:(Chill Downtempo) OR tag:(Electronic Downtempo)
Note how that operator can greatly simplify queries as soon as you add +3 values. Imagine trying to match 4 from 5 tags.
Great – I’d love some feedback on this work. Next time you’re in IRC, please PM me your email – I have new popularity datasets to share with you, if you’re interested.
And yes, the equivalence you wrote is correct.
As far as lucene – this isn’t going to get translated to lucene syntax, but into postgres SQL queries – I was just commenting that that syntax is similar.
And I totally see your desire to make these expressions fully boolean logic capable. Once I dove into what would be required to make it all happen (recursive descent parser and serious mental gymnastics of transforming boolean logic into SQL queries) I decided to keep it simple for now. Last.fm only allows listening to one tag for its tag radio (from what I can tell), so this is going far beyond their capabilities.
Our advisors (formerly last.fm staff) have also advised us that tag radio is useful, but artist radio is vastly more important – that is what most people used at last.fm. I am not sure how much people will use full boolean logic for tags, so I opted to have a simple setup as described above. If it turns out to be a hit and people are clamoring for full boolean logic, can implement that then.
Further to this, I think that most people are more used to search engine type parsing where the terms are somehow weighted by the most matches to the earliest terms entered, thus still including an item if not all terms are matched (albeit at a lower ranking in the return list). Sort of a fuzzy combination of AND and OR. I’m not sure this is appropriate or desired (or even feasible) for this application, so I’m happy defaulting to either AND or OR.
Why is someone entering two or more tags or artists?
They wish the radio to be more diverse. If you connect these entries with a logical AND, the result will be the opposite. The radio is less diverse and contains only those few tracks with both tags. With artists it would be close to empty. The default is not so important, if the user has an option to change the behaviour but from my point of view the logical OR connection is the better default.
If a user enters ‘cyberpunk’ + ‘furry’ or ‘united states’ + ‘black metal’ I feel it’s not expected to get completely disparate music - e.g. a track list with half black metal, half music from the united states.
Agree though that AND would have to be supplemented with OR. But surely tracks with all tags would be hitting the sweet spot?
Even if only the first result is united states blackened furry cyberpunk I feel like that’s super powerful. I guess I’m still thinking it should include both AND and OR but with different weightings.
I’m hoping an upcoming feature is to be able to include subgenres then? like if you specify metal with genre:[metal MBID]:subgenres it would also pull in Power Metal, Black Metal, and Blackened Death Metal. I’d imagine this could work if you specify it as a tag too, tag:(metal):subgenres.
I may make a ticket for this tonight, if that’s not in the plan…
edit: one thing @aerozol mentioned when he shared the link with the Discord server is it doesn’t seem to work well if the recordings aren’t properly tagged… I also see this as a fairly major issue, at least until we can add recording tags directly from ListenBrainz (a feature I’ve seen in several of the redesign mockups). perhaps we could later expand the tags it looks for to include releases/release groups?
This will play 2 parts from tag “deep house” on medium mode, 1 part from tag “metal” on hard mode and 2 parts from artists “Blümchen” on easy mode. And serve for a fair amount of ipod whiplash.
Please take a look and see if you find any bugs or clear improvements that ought to be made. Please keep in mind that this is far from ready to go into production and it intended for community testing. We’ll create a much nicer interface for this later, but right now this is what we’re using to test the underlying tech we’ve created. (without AI, at that!)
Questions, comments? Post them here for the time being. Happy playing!
Yes, the UI is terrible – but I also knew that people were would overcome that. We’ll build at least two more interfaces for this to build out the feature set and make it easier to use.
As for similar artist relationships – the data is just on the edge of usable. There are literally times when we’ve been able to see our own tastes in the data, which clearly shows that we could use more user submitting more listens and that should improve this data over time.
Especially on hard mode – some of that data could get squirrely.