|
|
For Playlists you can only select the is or is not operators, it would be good if other operators like is known or is unknown. 1. Is known would show any files on any Playlist 2. is unknown would show any files not on any Playlist image.png (21,342 bytes) |
|
|
Seems useful, to be able to see 'Tracks contained within any playlist' or 'Tracks not contained within any playlist' but the wording 'Playlist _is known_ or _is unknown_ is unclear. Perhaps instead: Playlist _is any playlist_ Playlist _is not any playlist_ OR alternatively, Playlist _is_ ( ) Any playlist (o) Specified playlist(s) . [ ] Playlist 1 .... and Playlist _is not_ ( ) Any playlist (o) Specified playlist(s) . [ ] Playlist1 ... Thoughts? |
|
|
Maybe the naming like this: 'is in any' => Track belongs to at least one playlist 'is not in any' => Track belongs to no playlists 'is in' => Track belongs to the selected playlist 'is not in' => Track does not belong to the selected playlist ? Nevertheless it seems to be quite complex to find whether a track is part of an auto-playlist, it would require querying all auto-playlists in library which would be a huge performance penalty But for static playlists the operation would be instanceous, does it make sense to make it function for static playlists only? |
|
|
We'd have to tweak the wording slightly. If I understand correctly, you're thinking along the following lines? Playlist - _Tracks are in at least one regular playlist_v_ Playlist - _Tracks aren't in any regular playlists_v_ Playlist - _Tracks are in one of the selected playlist(s)_v_: PlaylistName1, PlaylistName2,... Playlist - _Tracks aren't in any of the selected playlist(s)_v_: PlaylistName1, PlaylistName2,... That could work, but afaik it's unlike any of the other criteria (i.e. for every other criterion MM doesn't indicate 'Tracks have criterion> = x'. On the other hand, the approach discussed earlier is also a bit unclear as it doesn't communicate the 'contained within' aspect properly: Playlist _is_ ________ Playlist _is any regular playlist_ Playlist _is not_ ________ Playlist _is not any playlist_ The following approach deals with both weaknesses, I think. i.e. when the user click 'Playlist' --> In playlist _= any regular playlist_ In playlist _= no regular playlist_ In playlist _=_ _PlaylistName_ In playlist _≠_ _PlaylistName_ It's better because it follows the approach used for other criteria more closely but clearly, and because '=' / '≠' better conveys the intent than 'is'/'is not'. |
|
|
I'm not sure that the characters are better than words. I'd assume that a good chunk of the population does not know what they mean. |
- Anonymous
