Custom Tag finding

[fabolous005]

Hey,

to allow better organizing of one's music library it would be very useful to allow the user to define tags that should be looked for in the metadata.

Either in terms of a tag array or even like a map.
AFAIK there is no established way to save stuff like this...

This would greatly improve the functionality of the search feature and would be very practical for something like Spotify's smart shuffle functionality for the future.

What is your opinion on this?

[agersant]

This isn't a feature I have thought about before. Could you elaborate on how you would use the custom tags (is it just for smart playlists?), and example of tags you would use?

To set expectations, this isn't going to be added any time soon but may be in scope.

[fabolous005]

Thanks for reaching out,

I would use this to allow further categorizations for example setting the main instruments, the songs mood, the artists gender, ...
Basically all information one could get from the accusticbrainz api.

And actually i've started working on an implementation on this, but so far it's untested and i haven't fixed any failing test's yet.
Let me know what you think!

[saecki]

Regarding mp4 a single string key for a tag won't directly map, because mp4 uses a mean and a name string for custom tags. The mean is commonly a reverse domain name such as com.apple.iTunes, but I guess you could just ignore it...

[fabolous005]

Yeah mp4 was very confusing and i'm still not sure how it's stored, but i'm gonna look into that.

Btw just tested custom tag finding successfully (at least for flac files) for all combinations (weight, collection).
Gonna test other fileformats now...

[fabolous005]

I think we should talk about how exactly we should treat the collection ability...
As mentioned in #240 comma is not valid separator, but we could let the user define a custom separator for their own tags.
Not sure about artists though...

But in my opinion we shouldn't try to handle all possibilities to separate artists, but decide on one way, how we want to do it.

[saecki]

I think before diving too deep, more thought should be given about how this is used by/presented to the end user. And @agersant probably has an opinion of how that will fit the usually rather minimalistic vision of polaris 🤔

[agersant]

This is my cue to plug the (recently added) contribution guidelines.

Clarifying in the context of this feature:

• I'm very supportive of efforts like this where people modify/extend Polaris to better suit their use cases. It also makes me happy that the code is simple enough that it isn't a huge pain to do so (hopefully).
• As mentioned in the guidelines above, this is not something I would accept as a PR - regardless of code quality and the implementation details that are picked.
• As @saecki mentioned, the vision for Polaris has always been minimalist and opinionated. At the moment, I don't see myself adding this feature to mainline. But Polaris scope and my opinions do evolve over time. This feature isn't egregiously out of scope so my stance is "keep the ticket open, see if a lot of people do want this, try to understand how they would interact with it, maybe reconsider".