-
Notifications
You must be signed in to change notification settings - Fork 2
Collections
This concept was implemented as part of Google's Summer of Code 2006. For more information, see SoC:Collections.
Some XMMS2 clients want to use collections. It could be useful to brainstorm on that topic to see whether it is best implemented in the client or the server. To do that, we should first agree on what is a collection and what it is used for.
Please note that this is my conception of collections, which fits in my grand dream of creating a "better music player". Read my manifesto for more on that; what I present here is more or less a standalone version of the Collections and playlists: two main orthogonal concepts section of that document (near the end).
It is also related to the Smart_playlists page. It just extends the discussion.
Definition: « A collection is a subset of the Library. »
Notes:
- I use Library to mean "the set of songs in the medialibrary".
- Subsets are not ordered and therefore not playable. They are just an arbitrary set of songs.
- There exists no player that offers collection in that form, as far as I know. At best, they offer dynamic playlists, but it is not the same (see below).
So, pretty straightforward eh?
- "All songs added the past week."
- "All songs rated 4 or more."
- "All songs released before 1975 in the Psychedelic Rock genre."
- "My 30 favourite songs to wake up with."
- "All songs I have never played, except Britney's Toxic which is really on my harddrive because my g/f likes it."
We can distinguish three different types of collection here:
- Examples 1-3 are "dynamic", i.e. they result from a query in the medialibrary. If the medialibrary changes, the content of these collections will automatically be updated.
- Example 4 is "static", i.e. it's an arbitrary list of songs chosen by the user, which will not change unless the user adds/removes songs to it.
- Example 5 is a mixed version of the above, as it combines a dynamic set with a manual exclusion of a song.
Note: all three collection types can actually be implemented as medialib queries. The static collection can simply correspond to the SQL condition "WHERE id IN ([list of ids])" for instance, and the exclusion of Britney's infamous crap can be a simple NOT clause.
These different classes are important. Or rather, their separation in classes is not, but the possibility they offer is. There is nothing more frustrating than to have collections that correspond to a query but which you cannot add songs to or remove from. Surprisingly, that's how dynamic playlists (see below for collection vs playlist discussion) work in iTunes, Winamp5 & co. To my knowledge, Madman is the only player that allows edition of dynamic collections.
So if we agree on the idea that « a collection is a subset of the Library, » let's move on and see how it fits with existing concepts of music players.
No.
A playlist is an ordered list of songs, meant to be played in a sequence. We already have them in XMMS2.
A collection is an unordered set of songs. It is not meant to be played, it's just there to let you group songs together or access specific subsets of the Library (see the examples above).
It can be argued whether we need this separation or even the concept of collection altogether. The answer lies in the usage patterns of users:
- They often keep a huge list of songs in their XMMS/Winamp playlist and use the queue feature to jump from songs to songs. Why? Because they don't want to move songs around in their tidy list of songs.
- They love iTunes Party Shuffle, because it allows them to dynamically "feed" a playlist from a group of song they have constituted (another playlist, in iTunes).
People use playlists as collections, because the concept of collections does not exist in their player. They use the clumsy queue feature to have a playlist in the playlist.
But the absence of clear collections is inconvenient. Usually, it implies that you can only browse "collections" as a flat list, instead of using a cleverer browsing mechanism (e.g. the iTunes filters). It implies that you cannot derive two playlists from a collection (there is only one queue).
Browsing a collection should really provide the same comfort as browsing the Library. As a matter of fact, the Library itself is a collection (the subset that spans the set itself)! We could then see collections as filters that apply to the Library. They can be hierarchically organized, with the Library at the top of the tree.
To play songs from a collection, you simply create (or instantiate) a playlist from its content. Either all of it or some selected part. Or even, you can randomly feed a playlist from a collection, which becomes the equivalent of iTunes Party Shuffle.
Okay, to sum it up: collections allow the user to browse chosen subsets of the Library and to constitute playlists from these subsets.
More concretely, assuming we agree on the abstract concept of collection presented above, we should think a minute about what we would use them for and thus, would it make sense to implement them on the server?
No matter what interface your client has, you probably want to provide the user with a way to browse the Library. This implies more or less advanced queries in the database and displaying the results. As we saw above, collections are really just conditions in a query, so browsing a collection or executing a search from inside a collection is simply a matter of appending the collection conditions to the user's.
From a technical point of view, queries are made using xmmsc_medialib_query.
- In a client-side approach, the client would handle the inclusion of additional conditions to its query.
- In a server-side approach, the client would specify a collection name and the server would handle the inclusion of additional conditions.
In the latter case, modifying the SQL query is not really feasible so the solution would rather be to use database views corresponding to collections. Sounds possible, but then clients would have to query those tables (similar to the songs table perhaps?) and not the Media table.
So let's open the discussion here... The XMMS2 used to push for an "all in the client" approach, and it probably leaves more freedom to the clients, but also replicates the problem for all the client devs to solve on their own...
The easiest manipulation is to add one or several songs from a collection to a playlist. Right now, the clients can only add songs by id. When they add songs from a search in the Library, the client simply knows the id and adds it to the playlist. Adding songs from a search in a collection would be similar.
Where it gets more tricky is with Smart Playlists. Whenever one song finishes playing, a new song should be randomly selected from a chosen collection and enqueued in the playlist. The client could do it (reading PLAYLIST_POS_CHANGED events), but how would it remember "playlist metadata" (which collection it is bound to, how many entries to keep in queue, etc) ? It would of course be nicer to have the server do it, so that would imply that server knows about collections...
Okay, it's by far not a complete overview of the problems, but I hope I exposed one (my) view of the question and pointers to subsequent problems related to the implementation of collections either in the client or the server.
I am curious to hear about what you have in mind when it comes to collections, and possible solutions to the problem they might cause.
- How I Learned to Stop Worrying and Love Collections
- Continued Thoughts on Collections
- Reply to 'Continued Thoughts on Collections'
- Reply to "Reply to 'Continued Thoughts on Collections'"
- Reply to "Reply to 'Reply to 'Continued Thoughts on Collections''"
- Reply to « Reply to "Reply to 'Reply to 'Continued Thoughts on Collections''" »
- Subsequent Reply
Content is available under GNU Free Documentation License 1.2 unless otherwise noted.
- Community
- Development