The rule tree is sound; its vocabulary is thin. Predicate has fourteen variants — title / artist / album contains, genre, year and BPM and duration bounds, format, hi-res, liked, minimum rating — inside an all / any / not tree with sort and limit. Everything a rule could reasonably want beyond that is missing.
What to add
More library fields. The obvious absentees are the ones people actually build playlists on: play count and last-played date, date added, sample rate and bit depth as their own predicates rather than only through the derived HiRes, disc number, comment, and path or folder. Play history is already there as play_event with listened_ms per listen, so "played more than N times" and "not played since" are joins, not new data.
Any tag present in the files. This is the one that changes what the feature can express: a rule on a tag the user's own tagger writes — a rip source, a mood, a catalogue number. Offer the tags actually present in the library, with a count, not the theoretical list.
A live match count while the rules are being written. "Greater than" and "at least" explain themselves badly; a counter dropping from 3 000 to 12 as you type removes the doubt entirely. Cheap to serve, since the engine already builds the query.
Starting points. A handful of ready-made rule sets, and — more useful than it sounds — the ability to replace an existing playlist's rules with one of them. Starting again from a known-good set is precisely what repairs a playlist someone has tangled.
Say the rules in plain language on the playlist header, so a smart playlist explains itself without opening the editor.
Traps
- Everything binds, nothing interpolates. Field names and values alike must go through bound parameters — including user-supplied tag names. The one place this is unavoidable is
ORDER BY, which SQLite will not take as a bind; that fragment stays hand-rolled and closed over a fixed set of sorts, as it is today.
- Adding a variant to
Predicate changes a serialised shape that stored playlists carry. Existing rows have to keep deserialising.
- Whatever the new fields are, they need indexes or they need to be honest about cost — there is already a partial index on
track.rating for exactly this reason.
- New strings go to all 17 locales.
The rule tree is sound; its vocabulary is thin.
Predicatehas fourteen variants — title / artist / album contains, genre, year and BPM and duration bounds, format, hi-res, liked, minimum rating — inside anall/any/nottree with sort and limit. Everything a rule could reasonably want beyond that is missing.What to add
More library fields. The obvious absentees are the ones people actually build playlists on: play count and last-played date, date added, sample rate and bit depth as their own predicates rather than only through the derived
HiRes, disc number, comment, and path or folder. Play history is already there asplay_eventwithlistened_msper listen, so "played more than N times" and "not played since" are joins, not new data.Any tag present in the files. This is the one that changes what the feature can express: a rule on a tag the user's own tagger writes — a rip source, a mood, a catalogue number. Offer the tags actually present in the library, with a count, not the theoretical list.
A live match count while the rules are being written. "Greater than" and "at least" explain themselves badly; a counter dropping from 3 000 to 12 as you type removes the doubt entirely. Cheap to serve, since the engine already builds the query.
Starting points. A handful of ready-made rule sets, and — more useful than it sounds — the ability to replace an existing playlist's rules with one of them. Starting again from a known-good set is precisely what repairs a playlist someone has tangled.
Say the rules in plain language on the playlist header, so a smart playlist explains itself without opening the editor.
Traps
ORDER BY, which SQLite will not take as a bind; that fragment stays hand-rolled and closed over a fixed set of sorts, as it is today.Predicatechanges a serialised shape that stored playlists carry. Existing rows have to keep deserialising.track.ratingfor exactly this reason.