foo_queuecontents - View and edit queue Options

[kerpondile]

foo_queuecontents enables the user to edit and view queue contents through an ui element. Both the Default User Interface (DUI) and Columns User Interface (CUI/uie) are supported. As a legacy option, queue contents can also be viewed and edited by a special queue playlist, which is updated automatically with queue contents.

Newest version: 0.5.1 / 2012-03-11

For more information, please see the Wiki page.

Links:
Homepage: http://sites.google.com/site/salskisite/foo_queuecontents
Download the latest version: Official component repository

Source code: github (Please see the license files)


Please add any comments, I appreciate them!


Sami Salonen

This post has been edited by kerpondile: Mar 11 2012, 10:21

[Horst Fux]

This is just awesome, since foo_queuemanager doesn't work anymore I was looking for a nice alternative.

Great plugin, keep on working!

The only sad thing is, that I had a party some days ago and you released this plugin but now.

[kerpondile]

Thank you! I appreciate it. The main reason I made this component was that there's really no plugin that does the job properly.

Please tell me if you find any bugs or have improvement suggestions and I see what I can do.

-kerpondile

This post has been edited by shakey_snake: Aug 18 2010, 00:18

Reason for edit: Removed useless full-quote.

[s33m33]

Used foo_pqview till now, but it had limitations.

Thank you for your hard work compiling a much required component. Does what it says.

Will have fun playing around with foo_queuecontents.

[q-stankovic]

Reordering in Queue Playlist causes that numbers in column "playing" disappear and so foobar forgets wich playlist and wich playlist entry the queued item belong.


Edit:
If that is by design to make the component work so i must say that this is the craziest component ever: it destroys origin functionality of the queue to force some features the queue wasn't designed for.

This post has been edited by q-stankovic: Jul 27 2009, 17:07

[Yotsuya]

Reordering in Queue Playlist causes that numbers in column "playing" disappear and so foobar forgets wich playlist and wich playlist entry the queued item belong.

I suppose this is the same bug, but if you rearrange items on the queue playlist the value of %queue_index% for the tracks on their original playlist are destroyed. Also, it would be nice if settings such as playlist name for the queue were accessable from a File> Preferences> Tools submenu.

[kerpondile]

Playlist name can be set in the 'Advanced'->Display -> 'Queue Contents Editor playlist name' (should change this to something more descriptive...)

I will look at the reordering thing but I think it was the only way I could think of to implement that feature

This post has been edited by shakey_snake: Aug 18 2010, 00:18

Reason for edit: Removed useless full-quote.

[kerpondile]

Reordering in Queue Playlist causes that numbers in column "playing" disappear and so foobar forgets wich playlist and wich playlist entry the queued item belong.


Edit:
If that is by design to make the component work so i must say that this is the craziest component ever: it destroys origin functionality of the queue to force some features the queue wasn't designed for.

I found the correct way to do the queue reordering. Problem is now fixed in the next version 0.1.1. Component can be downloaded from the same URL http://sites.google.com/site/salskisite/fo...?attredirects=0 or using the homepage.

This should also fix the issue Yotsuya reported.

Please, tell me how it works for you.

-kerpondile

[durch]

Is this the same Columns UI does with "View/Columns playlist/Activate now playing" command?

[zygzak]

It would be possible to save queue between Foobars2000 sessions?

[kerpondile]

Is this the same Columns UI does with "View/Columns playlist/Activate now playing" command?

I haven't used Columns UI in a while so I can't be really sure. What does that do?

This component shows the queue contents in a separate playlist. Playlist can be edited and reordered and the changes are automatically reflected on the queue too.

It would be possible to save queue between Foobars2000 sessions?

It sure is possible. However, I think it outside the scope of this component (?). What do others think?

This post has been edited by shakey_snake: Aug 18 2010, 00:19

Reason for edit: Posts Merged.

[Xezzy]

Except if you dont mind changing name to foo_queuemanager (or something more relevant) or if there is another plugin with similar functions.

Personally, I would love to see plugin that is all-about managing queues, as someone mentioned, its very usefull at parties.

[mixcherry]

It would be possible to save queue between Foobars2000 sessions?

It sure is possible. However, I think it outside the scope of this component (?). What do others think?

I believe that the queue is not saved by design (It's Not a Bug, It's a Feature! ). The queue itself was discussed in different (long and boring) topic, and AFAIR core developer(s) stated there that the queue should remain plain and simple. I think that is the reason you had to do 'tricks' in your code responsible for changing queue items' order - because the queue is not intended to support such operations.


In other words, if you improve your component more and more, what will be the difference between using it, and using simple playlist with 'Remove After Playing' plugin (I remember that such thing existed somewhere)? You can already quickly send tracks to another playlist (eg. named 'Party' or 'Queue') using context-menu command.

I don't want to sound discouraging here, as I believe that great number of users don't agree with core developers and were looking for component such as yours.

Good luck

This post has been edited by mixcherry: Jul 28 2009, 19:14

[Xezzy]

Uhmm, good point mixcherry.

[Anas]

Thank you very much, kerpondile. This is much requested and, at least for me, needed functionality. Excellent work.

Component works flawlessly for me, by the way. Just one small request: It would be nice to have the lockname to be a bit more "appealing", because I'm displaying it next to the playlist's name.

[zygzak]

My point is: if we have queue that looks like playlist, is managed like playlist, it would be nice if it saves automatically when foobar2000 is closed as other playlist do.
If it will be done by foo_evilqueuesave, no problem for me.

[mixcherry]

My point is: if we have queue that looks like playlist, is managed like playlist... then why don't we just use playlist? Ohh, nevermind, I don't want to start flame war...

I bet that the very next request from some user would be 'not to flush whole playback queue' on playing track from outside the queue while it's being processed. Let alone implementing the 'simple' thing of saving queue's contents on exit.

I think that kerpondile made a very good foundation to create some kind of 'Advanced Queue' component, which would not base on core's (rather limited) functionality. Maybe it should be some kind of locked playlist which would disappear when it's empty (and reappear when someone adds track to it), and would automatically remove tracks from itself after playing them. Maybe for 'parties' it would have configurable options what users can and can't do with it (eg. allow/disallow to reorder, remove, etc.) And it would add command to context menu similar to the original queue. Maybe there could even be more than one queue!

Now, any 'improvement' to the original queue can lead to abuse of the core developer's intention, and I wouldn't be much surprised if it were banned for violating SDK license.

This post has been edited by mixcherry: Jul 28 2009, 20:01

[Yotsuya]

I'm posting to confirm the latest version fixes my previously stated issue with breaking %queue_index%, however I felt the need to point out that the Queue playlist doesnt honor any %queue_index% at all.

This component opens up some interesting uses for the playback queue but it needs to mature a bit. As for the whole "Foobar2000 best practices" debate, if you dont like the component dont use it. I'm always willing to explore new ways to manage my massive collection of music and nothing comes close to foobar on windows, mac, or linux.

[mixcherry]

Where did I say I don't like this component? I'm using it right now All I say is, the more this component is 'extending' core's queue possibilities, the closer it gets to normal (limited) playlist behavior. Whereas I'd like to see component that would start from being normal (locked) playlist and then be extended by new capabilities (like those that I mentioned in my previous post). I think that would be easier to program too, than hacking all core's queue restrictions. Anyways, I wish kerpondile all the best, because it is always good to see new potential in developers area

[q-stankovic]

I am very aware that kerpondile surely put much effort in the development of this component. Also i am not interested to start a long and boring discussion about queues functionality.

But:

I hope i am allowed to mention that this component and all its praising is absurd. As mixcherry already said: All you can do with this component is possible without it - not in the sense of a workaround but in identical way if you use foo_utils. What is the long requested and needed functionality some people are talking about? Maybe you don't know foo_utils? Ok, now you know it! All the requests i read in this thread so far are realizable. Furthermore you don't have any restriction as you use a real playlist. You are not limited to 64 tracks and you also can choose playbackorder for your playlist. And if you like played track to be removed you can use foo_removeplayed

How far will the request concerning this new component go? mixcherry already bets that people will request to avoid flushback queue on starting another track manually. I bet that someone will request to start tracks inside of queue playlist manually or to avoid removal of played tracks. Such requests doesn't only mean ignorance of already existing funcionality but also confusion about the queue itself.

This component would only makes sense if and only if it wouldn't show the queue in a playlist but in a panel outside of the playlist view. So the queue would be recognizeable as queue.

This post has been edited by q-stankovic: Jul 29 2009, 16:43

[FavioD]

thanks for this, very useful

[sPeziFisH]

AFAIK the only thing that makes a queue interesting is that it gets focus if it is filled with 1+ tracks and after being processed the last non-queue-track gets focus back again. AFAIK there is no way to give any playlist this feature of priority or does it?

Sometimes things come to your mind and you feel the need to put certain tunes into the stack, exactly at that time, right between your movements, even changing order of this temporary-set can be seen.. A PJ knows what I mean, but his live is hard.

[durch]

I agree it would be great if the queue would be a panel. Because I personally don't use the default UI, I'd prefer a Columns UI panel.

Own panel would give users well-proven Winamp-like queue functionality - a feature foobar2000 should have had right from the start IMO.

[kerpondile]

I believe that the queue is not saved by design (It's Not a Bug, It's a Feature! ). The queue itself was discussed in different (long and boring) topic, and AFAIR core developer(s) stated there that the queue should remain plain and simple. I think that is the reason you had to do 'tricks' in your code responsible for changing queue items' order - because the queue is not intended to support such operations.


In other words, if you improve your component more and more, what will be the difference between using it, and using simple playlist with 'Remove After Playing' plugin (I remember that such thing existed somewhere)? You can already quickly send tracks to another playlist (eg. named 'Party' or 'Queue') using context-menu command.

I don't want to sound discouraging here, as I believe that great number of users don't agree with core developers and were looking for component such as yours.

Good luck

Yes, I understand your point and agree on some point. I believe users should be able to see and edit the queue and I think the only 'clean' way to do it (within the standard UI) is the playlist. I wanted to make this component a panel but I'm not that interested on foo_ui_columns etc. As far I know, it's not possible to create panels with current SDK.

I am very aware that kerpondile surely put much effort in the development of this component. Also i am not interested to start a long and boring discussion about queues functionality.

But:

I hope i am allowed to mention that this component and all its praising is absurd. As mixcherry already said: All you can do with this component is possible without it - not in the sense of a workaround but in identical way if you use foo_utils. What is the long requested and needed functionality some people are talking about? Maybe you don't know foo_utils? Ok, now you know it! All the requests i read in this thread so far are realizable. Furthermore you don't have any restriction as you use a real playlist. You are not limited to 64 tracks and you also can choose playbackorder for your playlist. And if you like played track to be removed you can use foo_removeplayed

How far will the request concerning this new component go? mixcherry already bets that people will request to avoid flushback queue on starting another track manually. I bet that someone will request to start tracks inside of queue playlist manually or to avoid removal of played tracks. Such requests doesn't only mean ignorance of already existing funcionality but also confusion about the queue itself.

This component would only makes sense if and only if it wouldn't show the queue in a playlist but in a panel outside of the playlist view. So the queue would be recognizeable as queue.

I actually did not know about foo_utils. It seems to work very well. In an ideal situation my component would be a UI panel which could be placed where ever the user wants. Unfortunately this is not yet possible and the playlist seemed like the only way to it. However, after seeing how well foo_utils performs the same task, I'm wondering if my component is worth developing more.

I agree it would be great if the queue would be a panel. Because I personally don't use the default UI, I'd prefer a Columns UI panel.

Own panel would give users well-proven Winamp-like queue functionality - a feature foobar2000 should have had right from the start IMO.

I'm personally not interested in Columns UI and I think there's already some plugins to do this in Columns UI.


I never really had the intention to add 'queue save' and other extra features because it's not very wise using the current SDK. SDK has quite crude api for queue (maybe intentionally?) and therefore making the job not feasible/rewarding. This plugin works in its basic job and adding new features on top of foobar queue is not wise. I'd have to take totally different approach to this (as some of you have suggested) problem if I'd like to bring more features.

I personally am going to change to foo_utils + remove played combination because it gives me more control and achieves basically the same thing (more cleanly at code level). When foobar SDK will support the standard panels I'm willing to take a look at the situation again.

[q-stankovic]

Hello kerpondile,

my point wasn't only that foo_utils does the same job better but also that this job doesn't belong to queues functionality to override playback order during playback and to jump from playlist to playlist. And this functionality seemed to be forgotten or confused by many users - this confusion is forced by the fact that a playlist is used to mirror the content of the queue.

It would be a great pity for you after your effort to stop development before doing the last step. Sure, it is not possible to develop your component as ui element - but why don't you choose a free-floating pop-up window (callable by Mainmenu -> View->Playback Queue)? That would also be a clean solution and that is the way winamp users handle their queue since years without feeling the need to have the "Jump to File" window integrated into UI.