Proposal: generalize playlist concept
bart.cerneels at kde.org
Sun Jan 11 13:58:26 CET 2009
You've independently stumbled onto a conceptual ambiguity regarding
The Playlist. This is something I've spend some considerably time
You should read this thread on the dev list:
Top posting because the the original is to long to read through for
most people, sorry Pavel.
On Sun, Jan 11, 2009 at 3:34 AM, wrote:
> This proposal is quite long and even divided into sections. It is hard
> to explain what i mean without working prototype but after my attempts
> to implement it i realized that i can't do it all alone. So, instead of
> prototype, you get a long description.
> I tried to be more comprehensive instead of being shorter. Sorry, but i
> don't see any way to shorten my proposal but to skip section 0 and stop
> reading after section 3 or 4.
> 0. DISCLAIMER
> Sorry again, i only started trying to contribute to amarok a couple of
> weeks ago, so i dont know whether this proposal is new to amarok's pile
> of proposals. I also don't know whether some kind of this was
> implemented in other music players so please, let me refer to is as to a
> `new' feature, can i? :-)
> If such proposal has already been encountered then i hope i contributed
> someting to it at least.
> It was inspired by dynamic playlist. After i saw dynamic playlists, i
> first thought you will do it the way i propose, but, after i saw queue
> implementation, i realized that it was wrong, thinking that.
> 1. PROBLEM
> I would like to start description from the problem, but it so happens
> that there's no problem. :-) It's just an improvement, uncommon and
> unclear to users (when described verbally), but the end result may occur
> Okay, here's my view.
> The thing is that playlist in modern music players utilizes two
> functions at once:
> a) keep manually selected (with automatic filling capabilities, such as
> `add directory', `drag from collection') array of tracks; and
> b) visualize iteration over that playlist with selection of one track,
> queue markers etc.
> Time passes and ways of iterating through the playlist keeps improving
> from straightforward track-by-track playing: random movement, queuing
> and dynamic appending tracks to it (called in Amarok dynamic playlist).
> But what is the playlist: an array (random-access), a list, a stream or
> a set? The playlist container switches its nature when different type
> of iteration is selected.
> I can't call it a problem, but i can definitely say that the lack of
> logic means that something can be improved.
> 2. PROPOSAL
> I noticed one thing. Whatever track picking procedure we use, the
> result of it is a mere `stream' of tracks being picked from playlist,
> collection -- i.e. from lists that utilize (a) concept. If we start
> writing tracks, that are actually played, in a list, we will get a
> simple playlist (possibly infinite) which contents are played consequently.
> If something utilizes (a) concept, it shouldn't necessarily utilize (b)
> concept: colleciton, for example, can't be iterated through (in amarok
> 2.0, and it's right!). We call such objects a `set' (of tracks). Of
> course, if something utilizes both (like usual playlist with
> straightforward iteration)
> Let's call such stream a `generalized playlist' (in order not to mix
> with radio streams etc.). It contains manually selected tracks (like
> usual playlist) along with special tracks (i'll call them `factories').
> The factories feed the gen.playlist with new tracks when the iterator
> meets them.
> The tracks being fed are selected, according to the rules the factory
> comprise (they may be different), from a set or, if the rules allow,
> from another genlist.
> After factory has produced all tracks it should, it disappears from
> genlist and the iterator proceeds to (generalized) tracks after it.
> (for those who's involved in development, more simple terms.
> Generalized playlist is a playlist where all tracks are
> PlaylistNavigators, some of which yield one item (alias for usual Track)).
> `Ah, just a geeky feature', you say, `most users do not need playlist
> programming'. And you are right. But in this model simple tasks can be
> simply achieved and nicely visualized. The following section tries to
> convince you in it.
> 3. EXISTING FEATURES IN NEW TERMS
> All iteration features currently provided by amarok are generalized by
> the genlist concept and have better visual representation. Check it out:
> * Usual consequent playlist.
> A marker that just iterates playlist consequently is added into
> invisible genlist. Playlist window still contains plain old playlist.
> All usual playlist operations are supported but playing silently affects
> * Random iteration over playlist.
> A genlist contains factory that is tuned to randomly select tracks
> from other list. A tiny genlist appears in the topright corner of
> the screen which will show--like in tetris game--the next track that
> will be played after it.
> * Queueing tracks in random playlist.
> A track is simply dragged from main playlist to genlist, right after
> the track currentlry played. Genlist will first iterate to the enqueued
> track and then proceed to factory which will keep yielding random tracks.
> IMHO that's a much better visualization and interface for queue than
> the numbers near playlist entries.
> * Dynamic playlist
> That's also simple: dynamic playlist by its nature is a genlist with
> one factory that contains biased rules. A new bias can be introduced:
> you can select 50% of tracks from entire collection (1st bias) and 50%
> from the main playlist (2nd bias). Geeks can use the secret feature and
> add a generalized item to main playlist which will allow construction of
> complex biases without any additional coding.
> * Repeat on/off
> That merely affects whether factory produces infinite number of
> tracks or memorizes its choices (as RandomTrackNavigator does).
> * Stop after...
> A factory that looks like `POLICE LINE - DO NOT CROSS' is inserted
> to genlist via context menu and may be dragged. It yields no track and
> makes playing stop upon iterator reaches it.
> 4. NEW FEATURES THE CONCEPT PROVIDES
> Not only expresses the genlist old features better, but it also
> introduces more interesting features
> * Several playlists support
> Now playlist is not a singleton -- i.e. there can be more than one
> playlist that only contains tracks but isn't iterated through (i'll
> remind, that's called a `set' in this document). Only main genlist is a
> singleton. A special factory that iterates the playlist in its native
> order is used to implement it.
> * Advanced mixing with dynamic playlists
> I sometimes miss feature that allows me to apply dynamic playlist
> rule to manually picked set of tracks that can't be expressed in bias
> terms. That's one feature.
> Another feature was already mentioned - mixing different playlists
> into one. That's called `party mode' in other proposals. Several sets
> contain manually selected tracks or even factories, one set per user.
> These sets are mixed proportionally into main genlist via factory that
> implements dynamic playlist.
> Too few? Well, these govern at least one separate proposal. And more
> importantly, simple and sound (i.e. `non-contradictive') rules allow
> programmers to _discover_ new features and implement it with little
> effort. Vice versa, my experience shows that if feature is useful and
> sound it also fits a good logical system.
> 5. HOW IT AFFECTS GUI
> Screenshots would be nice, but i didn't fake them If your responce show
> that i failed to explain my thoughts, i'll paint them and post scans
> and/or implement genlist class hierarchy and show a little prototype.
> So the playlist windown in meantime looks like a usual playlist. It's a
> genlist, but it looks like playlist. Bottom bat provides factories that
> can be dragged into it.
> Old-style mode switching (turning on `random' or `dynamic' or `repeat')
> splits a window into two, where the upper one is our generalized
> playlist is set according to one of patterns described in section 3.
> And all tracks are copied into the bottom genlist (if necessary).
> Sometimes (when `repeat' is turned on) it's not necesary to even show
> the genlist, but just to keep in invisible and play tracks from it.
> Interaction with a set (double-click) that's not a main genlist just
> appends track to genlist after the one being played and causes
> triggering of `next' pressing.
> Several playlists are implemented as tabbed view. Main genlist isn't
> tabbed -- it's a singletone. The tab currently selected is a current
> playlist. It is the current playlist, into which tracks are inserted
> when user drags them from collection to specific zone of central widget.
> Many other special cases are all governed with GENERAL RULE: one main
> genlist, that handles pressing of NEXT and PREV buttons; it is shown on
> demand only or when user triggers some of the patterns in section 3.
> And several other genlists inside a tabbed view.
> 6. HOW IT CAN BE IMPLEMENTED
> I examined amarok source code and didn't find severe restrictions that
> would prevent it from being patched properly. First, a working model of
> factories and genlists must be implemented and tested in separate
> application. Then it must be imbued into playlist model, overriding
> Item class with GeneralizedItem.
> A new widget that draws factories must be created and the toolbar to add
> them to playlist are needed.
> All playlist management features like dragging, highliting of current
> tracks are implemented already). A bias editor for factories is already
> implemented, it's just needed to add some features into it.
> The most complex thing to do is desingletonization of PlaylistModel
> class. I think it was created as singleton but developers errorneously
> used it as singleton even in cases where it's not required (the most
> obvious case is using Model::instance() in TrackNavigators instead of
> passing the reference to model to navigator's constructor).
> What else? Uhm, if i missed something, it's not that big i suppose.
> Some key concepts will be touched, though i think that it's possible to
> keep source compatibility. More careful study needed but ---
> implementation question should arise after design ones anyway.
> 7. WHY I WROTE IT?
> I was going to implement it on my own, but first i'd love to know
> whether you like the idea. After i wrote some code i realized that the
> amount of work is too big to risk that you won't accept it. :-)
> Whith hope you'll reach this line,
> Pavel Shved
> <pavel.shved at gmail.com>.
> Amarok mailing list
> Amarok at kde.org
More information about the Amarok-devel