Hey Zak, thanks for your reply. Sorry I made you type the boolean stuff, though. I tried to post an update as fast as I could but it clearly wasn't fast enough. I should have looked at the updated documentation before posting anyway, so my apologies.
All good. It gave me a chance to brush on the search box keywords. And I could have searched the documentation too, but decided it would be more enlightening to wing it.
Regarding the intuitiveness of the operators, as you can see from the examples in my second post, it's already an issue.
It's only an issue if you regularly perform searches like this on a massive data set that returns too many false positives for what you're actually trying to achieve.
Don't get side-tracked trying to find perfectly parseable search terms - outing yourself as a developer at the same time - and overlooking what will already work, at least good enough if not perfectly.
"Tito & Tarantula" AND "Dust And Ashes"
"Tito & Tarantula" "Dust and Ashes"
(would narrow the results to both "Tito & Tarantula" and "Dust and Ashes", exactly. Boolean AND can be omitted with the quotes.)
As search terms are inclusive by default, this shouldn't really be an issue.
If you want to find the track "Dust and Ashes" by either "Tito and Tarantula" or "Tito & Tarantula", just search for
Tito Tarantula Dust Ashes.
I can't see how that could possibly return any false positives however large your library is. Obviously, that's one specific example, but I'm still struggling to think of any (all inclusive) search that doesn't already work if you specify enough search terms (or partial terms).
Searching for "all or nothing" and "Black or White" (without quotes) gave me the results for "all", "nothing", "black", and "white". Searching for them with quotes gave me no results at all.
Yep, searching for the word "or" within a tag is problematic. Given that quotes are already supported and the
or keyword is already supported, I would consider the fact that they can't be used together like this is a bug, not a missing feature.
From memory, the support for operators in the Search Box was added a long time ago and not really discussed since, which suggests most people aren't trying to use it for anything too complex. It could be revisited to make it more robust. No idea how it was first implemented, but I imagine there are third party libraries available that handle this kind of thing.
Directly editing the Track Gain value, however, would definitely be one of the biggest items on my wish list, especially since it's probably the easiest to implement–by far.
It sounds like you're talking about editing values as provided by enabling
Enable direct editing of tags in the main panel, and it does seem arbitrary which fields can be edited in the main view and which ones can't. Being able to edit the file name this way seems like it should be supported.
This still wouldn't let you edit a tag value for multiple files at once though. You could try using the
Tag Inspector for that. I can't actually see how to access that via the GUI, but you can assign it a keyboard shortcut.