Bug 63260

Subject: Re: soup style current playlist

I've been thinking for a feature like this on the last days.

The best way (IMHO) to do this would be a "queue" playlist. Much like the
"History" playlist, but instead of played songs, it would hold the
going-to-be-played songs.

That way, double-clicking a song would not play it but add it to the queue.
Perhaps it would be a bit tricky to code, but think about the possibilities
(people asking for songs, queueing gaps -should solve bug #60461- , queue
building and preprogramming -radio stations building a queue for the day- and
lots of stuff)

As in #60461, I'd propose adding some columns to the queue, such as "estimated
starting date&hour", "asked by".

Just an idea.

I've had a few people ask about this and my question alway is -- how is this different from what a playlist is normally?  I think this would confuse the interface by well, making a playlist not a playlist.

The idea behind a playlist is that it's a queue of thing to be played -- having a meta-playlist where you a "list of the things to play from the list of things to play" seems counterintuitive...

Surely at some point someone would suggest, "Well, shouldn't that be saved and restored?" and then at that point it's just a playlist...

*** Bug 65932 has been marked as a duplicate of this bug. ***

Well, the queue playlist would be dynamic, so the played items will be removed from it after the playing.. This is pretty nice feature when partying, so you can select eg. 20 songs and the order they're played and go away from computer..

Why not just create a new playlist and put them there?  That's what playlists are for.  :-)

Well, could there be a menu item that would allow to do it? And how can I turn on the feature which removes the songs from there after playing?

*** Bug 69126 has been marked as a duplicate of this bug. ***

I would like to have the at #2 requested feature as well.

@Scott;
it would differ from other playlist cause of it's behaviour (kind of marking what songs should be played next, even winamp3 has such a functionality).
Let's say you like to use juk at a party (with enabled kiosk-mode :) and people likes to choose songs from your collection to have them played later. With the intention to make that as easy as possible creating a newplaylist, choosing the songs and adding them to the playlist isn't a good solution. A regular playlist doesn't remove the songs from the list if they where played as well like a queue should do.
Each jukebox (even my own one http://www.dipe.org/?page=win/amp4u) does have such a queue-functionality. So, it would be great if juk could have it too.

I like to support this as wel (see bug# 67337).

You should be able to add (with context menu or middle click or control click) a song to a current playing playlist. See Noatun. When exiting Juk, there can be a dialog asking to save the playlist and if you do so, it will appear in the list of other (saved) playlists.

I think this can easy be setup and it will be (don't flame me) idiot-proof.

Cheers,

Jeroen

PS. I really like juk and like to put it in a bar environment, but this one is the most important wish I have.

This isn't all that different from ordinary playlists but the important thing is that it's a very useful UI shortcut.

For example, if I want to listen to more than one album, but don't want to create playlists for every combination of albums.  With the ability to 'queue' items in a special list I can just add stuff with a double-click or a context menu or whatever.

Not everybody uses the program in the same way, this feature would remove an irritation from the way I use it.

Apart from that it's lovely, good work.

I would like to support the idea of a queue to. Perhaps make it configurable, so that one can choose a playlist that recives all double-clicked files and append it.

BTW:
I just found about Juk. Except the above point (and perhaps auto-mixing) I was always searching for such a tool. Great work!

I've installed Juk in a local bar. All works fine, but this feature is really requested by everyone. There was even one barman who refuses to use Juk because it has not this fuature.

*Just doubleclick on a song from the collection and it will be added to the dynamic playlist. Middle click will play it right away and after finishing this song, Juk should continue with the dynamic playlist.
*Songs from the dynamic playlists are removed after be played (maybe this can be a preference).
*Dynamic playlists can be saved to normal (non-dynamic) playlists. Normal playlists can also be easily transformed to a dynamic playlist, via the context menu.
*Dynamic playlists will be emptied when quiting Juk. The can maybe also a preference.

I think this is the number ONE feature we need.

Cheers,

Jeroen

*** Bug 80936 has been marked as a duplicate of this bug. ***

*** Bug 81595 has been marked as a duplicate of this bug. ***

I think what needs to be done is to separate the "query selection" from the playlist. The playlist should be a list of songs currently playing, which can be arbitrarily reordered or reordered using filters. Songs should be able to be "queued" or played out of order, as with recent versions of XMMS. This should never be implicitly modified - only by explicitly loading a playlist. Searching in this list should jump to matching files instead of filtering.

Then there should be the "query selection", the list of songs being viewed depending on album/artist/playlist selection in the collection list pane and search operations.

To me, this seems more logical and easier to use than juk's current system. It would also allow, for example, for one to browse for a song or edit track data without losing one's current playlist.

iTunes have the notion of a "party playlist". What that means is just like the
library only that it randomize the playlist instead of having it sorted. IMHO this
function doesn't really bring that much to the table.

I agree with Wheeler that a "virtual" playlist which bears the trademark of just a
playlist isn't that inovative. However I do see the idea of being able to have
some sort of "party mode" in JuK.

So I was thinking, how about a having a button called "party mode" which switches
on/off. If you enable this feature you get a special "party playlist" and when you
now surf the library, doubleclicking a song will not play it, instead place it
last on the "party playlist".

When you set "party mode" to off JuK returns to it's normal state(clearing and
hiding the "virtual party playlist" and doubleclicking songs now play them).

Paryt mode seems like the way to do things, a simple UI extension for people who want it that doesn't get in the way of people who don't.

The ability to dynamically create a once-off playlist is, IMO, an absolutely essential feature for any program that calls itself a jukebok!

What do you think, Scott?

also see bug 69080: Request for automatic DJ functionality

This is a great suggestion. But don't add a party mode! It is a basic design concept that software should avoid having several modes, where everything works more or less differently depending on mode.

See my comment farther up (#15) about how to do this in a generic fashion without adding modes. This (clearing my current playlist when browsing music) is a constant annoyance when using juk, and I think that's an elegant, minimal-surprise solution.

Well, this is the only feature that's keeping me away from juk. The idea of a "current playlist", or "queued for play playlist", or "what's playing playlist" is just so basic to me that I've grown to depend on it, and expect it.

I think it's safe to say that many people want this, because it's such a great way to pick something to listen to in an instant, without having to create a static playlist and then afterwards delete it. And it's great if you want to play an existing playlist (which you want to keep saved as it is) but add or remove a few songs just this once.

With this you can _at any time_ add or remove songs from what you're about to hear, without having to worry if you're changing a playlist permanently.

Oh, and of course it would be best NOT to remove a song after it is played, you might want to play the whole playlist again, return to a previous song, loop the playlist...

This one definetely gets my "single most important missing feature" vote.

I totally agree with this BUT of course it would be best to make it configurable whether or not songs are removed from the playlist. It totally depends on the event if you might want to play the songs again or not. Last time people complained that the playlist was played over and over again with a constantly shrinking playlist they might have added some new songs :)

A fecha S

> However, the most difficult part about this (IMHO) would be an algorithm to 
> fill the "queue" playlist when it's empty. Fully configurable programming 
> would be very nice (think radio stations), but difficult.

Automatically fill the queue? I was thinking more of a simpler solution. You tell juk to play something, be it a single song or another playlist, and it gets added to the "queue", just like what happens in simple multimedia players like xmms (in fact, in that one you have the ability to choose if what you selected gets added to the queue, or replaces the entire queue; something like that would be nice in juk too).

Is it not the way that the needed functionality is already there? Play-Next creates a list of songs to be played next, even though at the moment the list has only one entry this is the functionality needed. Obviously there needs to be some work on other functionalities like, deleting items from the "instant playlist" but the adding would already work by allowing more than one item in the play-next array.

No. It's not quite that simple, as it requires a rethinking of the way playlists should be handled. (IMHO) I think what's necessary is a three-way division - a list of the songs in the current selection (eg, all songs by artists A, B, or C), a current playlist, and a queue of songs to be played after the current song. With JuK jumping to the next song in the current playlist if the queue's empty.

CVS commit by mpyne: 

OK, here it is.  This commit introduces a new feature to JuK, the upcoming
playlist (which is currently easily the #1 requested feature).  Although
there's still issues to be solved with it, it seems to work pretty well at this
point, I've been running this code for a few days now.

How it works so far:

* You must enable it by selecting "Show Upcoming Playlist" from the View menu.
* When the upcoming playlist is enabled, it takes over control of playback
  completely.  You can drag-and-drop tracks onto the playlist to add them to
  the end of the line, or you can use the context menu's Add to end of upcoming
  playlist entry.
* If loop playback is disabled, then entries will be added to the end of the
  playlist as entries disappear.
* Hitting Next (or double-clicking an item while a track is playing) will cause
  the currently playing track to disappear.  The History playlist doesn't play
  too well with the upcoming playlist yet, so if you want to keep the songs you
  played, you're better off making a normal playlist.
* On that note, double-clicking a song will add it to the beginning of the
  queue and immediately start playing it.
* Random play should work as normal.  If it doesn't, it's a bug.
* When the list becomes empty, playback stops.
* There is also a selection in the Settings menu, "Save Upcoming Tracks", which
  will save the current status of the upcoming playlist on exit.

This is a rather sizeable re-organization/addition of code, so if you
experience crashes/bugs in the next few days, PLEASE report them, and you can
probably assume it's my fault. =D

This feature will probably be tweaked over the next few days as well, but I
wanted to get it out there for testing.

I'm closing bug 63260 since this implements the feature.  If you'd like to
quibble on the specifics, feel free to continue commenting on the bug, I'll add
myself to the CC: list for it.

CCMAIL:63260-done@bugs.kde.org


  A            tracksequenceiterator.cpp   1.1 [no copyright]
  A            tracksequenceiterator.h   1.1 [no copyright]
  A            tracksequencemanager.cpp   1.1 [no copyright]
  A            tracksequencemanager.h   1.1 [no copyright]
  A            upcomingplaylist.cpp   1.1 [no copyright]
  A            upcomingplaylist.h   1.1 [no copyright]
  M +3 -0      Makefile.am   1.66
  M +17 -1     cache.cpp   1.27
  M +3 -0      juk.cpp   1.216
  M +3 -1      jukui.rc   1.50
  M +57 -122   playlist.cpp   1.244
  M +24 -8     playlist.h   1.134
  M +48 -6     playlistbox.cpp   1.117
  M +2 -1      playlistbox.h   1.67
  M +47 -2     playlistcollection.cpp   1.38
  M +16 -3     playlistcollection.h   1.18
  M +0 -1      playlistitem.cpp   1.94
  M +19 -0     playlistitem.h   1.59

I'm seeing quite a few problems...

A lot of crashes, difficulty finding what is currently playing, random play not working (when in Queue mode), and not being able to turn off the queue.  The "Genre" automatic playlist in a different spot than before, etc.

Could it be configuration problems on my end?  Or maybe because my juk is heavily patched?  Maybe.  I'm going to try compiling a clean copy...

Yeah - I think the crashes are my fault...but the other probles exist in a clean build with clean ~/.kde/config and apps...

1 - It appears that it's always in Queue mode - even when I don't have it selected.  If this isn't the case, then the behavior is WAY different than it was previously.  I understand that in queue mode, then the songs that should play are the ones in the queue, but when you aren't in queue mode, it should behave as before (play whatever is displayed dynamically)  This is my biggest issue I have...I don't understand how it works!  :)  (I guess I'll just do cvs update -dPD 2004.08.19.04.11.54

2 - I can't for the life of me get random play to work in queue mode...it always just plays from top to bottom.  Random play works fine in non-queue mode.

3 - "Genre" in tree-view mode now shows up between Artist and Album - instead of after them...This isn't that big of a deal...but I'm used to the old placement (alphabetical makes more sense anyway...)

Should these be reported as new bugs?  Or should this one be re-opened?

On Friday 20 August 2004 21:24, Nathan Toone wrote:
> ------- Yeah - I think the crashes are my fault...but the other probles
> exist in a clean build with clean ~/.kde/config and apps...
>
> 1 - It appears that it's always in Queue mode - even when I don't have it
> selected.

If you see the Play Queue in your list of playlists, that means it is enabled, 
whether or not it is selected.  What this means is that even if you 
double-click on a song in a different playlist, songs are still played only 
out of the Play Queue.

Of course, if the Play Queue isn't shown yet you're still unable to play music 
normally, you should open a new bug to report that.

> 2 - I can't for the life of me get random play to work in queue mode...it
> always just plays from top to bottom.  Random play works fine in non-queue
> mode.

The idea of a queue is that it plays things in order.  What random play means 
for the Play Queue is that if items are automatically added to the end, they 
are added randomly, as opposed to the normal sequential read from the 
Collection List.

> 3 - "Genre" in tree-view mode now shows up between Artist and Album -
> instead of after them...This isn't that big of a deal...but I'm used to the
> old placement (alphabetical makes more sense anyway...)

This would be unrelated to the playlist changes first of all.  Second, it 
appears in alphabetical order for me, so I'm not sure what's happening for 
you.

> Should these be reported as new bugs?  Or should this one be re-opened?

Since the Play Queue seems to have gone in without disaster, I would open them 
as new bugs instead of using this one.

> > 1 - It appears that it's always in Queue mode - even when I don't have it
> > selected.
>
> If you see the Play Queue in your list of playlists, that means it is
> enabled, whether or not it is selected.  What this means is that even if
> you double-click on a song in a different playlist, songs are still played
> only out of the Play Queue.
>
> Of course, if the Play Queue isn't shown yet you're still unable to play
> music normally, you should open a new bug to report that.

OK - I'll open a bug for that...when the play queue is not shown, it doesn't 
play normally.

> > 2 - I can't for the life of me get random play to work in queue mode...it
> > always just plays from top to bottom.  Random play works fine in
> > non-queue mode.
>
> The idea of a queue is that it plays things in order.  What random play
> means for the Play Queue is that if items are automatically added to the
> end, they are added randomly, as opposed to the normal sequential read from
> the Collection List.

It does do this...I didn't understand how it worked.

> > 3 - "Genre" in tree-view mode now shows up between Artist and Album -
> > instead of after them...This isn't that big of a deal...but I'm used to
> > the old placement (alphabetical makes more sense anyway...)
>
> This would be unrelated to the playlist changes first of all.  Second, it
> appears in alphabetical order for me, so I'm not sure what's happening for
> you.

OK - I'll try to figure that one out...

*** Bug 87650 has been marked as a duplicate of this bug. ***

*** Bug 91910 has been marked as a duplicate of this bug. ***

*** Bug 96928 has been marked as a duplicate of this bug. ***