This is a bit of an idea finding post as the library playlists support in Winamp is somewhat lacking at times based on what I’ve seen mentioned in the past.
So if a replacement plug-in were to be made, what sort of new features would be wanted in addition to matching where feasible the existing functionality of the native library playlists plug-in ?
From what I’ve seen mentioned over the years, I’ve got the following possible additions in no particular order:
- Displaying more information and even artwork (e.g. like the local library views can do depending on how they’ve been configured)
- Categories so its easier to manage / group lots of playlists (e.g. like the bookmark categoriser plug-in did for bookmarks)
- Additional save formats for easier interoperability (e.g. XSPF)
- Tracking of changes in source playlists when using the import option (using the actual playlist on import equates to this but it might be handy to have the imported copies track back when using a managed copy instead of the real playlist)
- Being able to generate a playlist from a folder without an existing playlist file present (e.g. you drag and drop a folder onto the playlists root view and you’ve then got a playlist automatically created)
If you’ve got any thoughts / suggestions on any of the above or what you think would make the library playlists support better then please comment below as I’m trying to plan out for later on what could be done with a replacement plug-in :)
-dro
Search ability.
And remove duplicates which is not avail at the moment
I assume you mean something like https://getwacup.com/images/ml_playlists_search.png for the search ? And would that just be per-playlist (like the mocked screenshot) or also as an option within the playlists root (so you can find the playlist that matches that way) ?
Remove duplicates makes sense (is something that the JTFE plug-in added to the main playlist editor but couldn’t easily be done to the library playlists - which a replacement would be able to natively do). So both are good suggestions :)
yes was thinking search per playlist but root could be an additional option too I suppose, depends how hard to impliment
Playlists is something I use very frequently also. Basically I have one playlist for every album. And every album in its own folder. format <Artist> - <year> - <Album><Artist> - <year> - <Album>.m3u. So I have over 700 playlists.
I insert the year so that the albums will be in chronological order in the folder structure and in the playlist node once I sort it from A-Z. Makes things easy to find. As you mentioned, it would be great if the playlist node worked like the audio node (If possible). One pane for artist, one pane for the playlists that artist contains, and the bottom pane that has the songs from the playlist or artist selected. Since the audio pane is powered by metadata you might not be able to read playlists the same way.
Even if it were two panes so that if you click on the playlist node in the nav pane, in the right it lists the playlist title and then when you highlight it you can see all of the songs in that playlist. Anything so I do not have to click the down arrow next to playlists in the nav pane and try to scroll down that.
Gosh I hope that made sense!
Pete: Not that hard once you’ve got single playlist search working as it can then just be done in a loop over the contents.
Juanus: Firstly I’ve added some line breaks to your comment to make it a bit easier to read (hopefully the breaks work as expected based on the raw formatting of the message that I could see). Now onto topic, I remember someone had mentioned having 700+ playlists and slow loading times of the library to do with that so I’m assuming that was also you ? (as I cannot remember if I did anything under AOL to help reduce that issue or not).
It hadn’t entered my mind to do something like a local library -> audio view (default settings) for playlists with instead going with what is basically like the root local library view (i.e. a simple searchable list with customisable columns if that is chosen). So I don’t think at this moment matching it to be like the local library -> audio view is going to work (primarily due to needing to think about how to handle metadata caching, etc). Not to say that it cannot work and isn’t a good idea but it seems a bit at odds with how playlists are meant / expected to be dealt with. So will keep that one in mind but will most likely keep to a ’simple’ customised view as a starting point.
However the two pane option for the root sounds like a really good idea to me. As I find it a bit of a pain with having a smallish library window height and having more than a handful of playlists starts to involved navigation tree scrolling, so 700+ playlists must be a pain with how the native plug-in works.
I’ve made this mock-up which I think is what you’re talking about -> https://getwacup.com/images/ml_playlists_root_dual_pane.png It would also have a search bar at top of both parts but I’ve not put that on the mock-up. Hopefully that’s what you’re talking about for that option.
And as I’m thinking about things, such a root node could also help remove the need to have all off the playlists added to the navigation tree as child nodes of the root playlists node (if that’s what’s wanted via a config option) which for your usage case would also reduce loading times and all that fun :)
DrO.
Yes, I am the one that had the slow loading playlists from before. I remember that you did something that sped them up considerably before. However, only you would know what magic you worked. I guess I could look back in the forums to see what you said.
Thank you for being able to interpret my ramblings. That is exactly what I was talking about. It was late at night, I was tired and I wanted to get those ideas to you before you moved on to another plugin/project.
Removing the playlists from the navigation tree is another great option. And if that would help with load times, all the better. I also remember there was some issue with the column headers not being able to be customized. Is that something that you can fix with this? (sorry to keep throwing things at you, but I figure since you are under the hood, I will get it all out.)
Thanks
Oh, and I found the old thread where we kind of talked about this.
http://forums.winamp.com/showthread.php?t=357612
The video that I made still works. The wonders of the interwebs heh. Though I am sure that all of the changes have made the topic/solution null and void.
That’s good to know we’re both making sense to each other :)
I probably did something relating to minimising updates of the library tree as the playlist nodes are added or how the processing of the playlists.xml file is done. Is hard to know without the old AOL code commit logs to check. Though that doesn’t matter too much if thing were better after any changes I’d made - had vaguely thought I’d done something but wasn’t sure, heh.
Having a single playlist node and no child nodes with the number of playlists that you’ve got would be the best way of improving your overall Winamp start-up times compared to any of the other changes that I’m trying to make.
Just have to hope that two-paned view does work as a better way (it seems like it should from some further thinking about it all). As I’ll likely start off with it as a straight list of playlists (effectively as-is) but later on when category support gets added then it’d become a tree which might make things interesting (mainly relating to search results handling - though I could just provide them as a straight list of applicable playlists and a full tree if there’s no search entered).
I assume you mean how the size of the columns doesn’t honour what is manually set and instead reverts to a desired layout? If so then that’s easily done to get around that, with the existing layout used as the base layout of the view and then allowing the user changes to be remembered.
“I assume you mean how the size of the columns doesn’t honour what is manually set and instead reverts to a desired layout? If so then that’s easily done to get around that, with the existing layout used as the base layout of the view and then allowing the user changes to be remembered.”
I was actually trying to say how you cannot right click the columns and choose Customize Columns like you can with the other nodes. For example of your mock up. I wouldn’t want date modified so I would be able to right click it and choose the columns I want to show. But at this point I am being nit picky. You got my main idea and I am pumped that you like it!
Keep up the great work.
The customise columns thing is basically covered under the first item in the list I originally posted (displaying more information) but that’s primarily about the playlist views. For the root playlist node I hadn’t thought about doing it (mainly because there’s not much information) and instead just allowing for columns to be sized to nothing to hide them that way, but will have a think about it.
As the last modified thing, that’s something I’m thinking about as it might be helpful for some if they are working with the actual playlist (when imported) and not a managed copy (default behaviour that I’ll likely maintain but with some tweaks) so the playlists can then be sorted by that option for easier tracking of changes (at least that’s the vague idea from my mind at 2AM :) ). One thing that I do want to do is remove the sorting menu options and just make clicking the column headers in the root playlist view to do allow for that (which is a more expected behaviour).
Hi dro,
One more thing that have frustrated me in the past was the inability to update file locations in the playlists for files moved.
I actually stopped using playlists because of files that was moved/renamed to more appropriate disk location or another naming convention.
Showing which entries don’t have a file and the ability to find that file in either the Library or on disk would be a great enhancement.
I would also like the ability to add a custom sequence in the playlist (Don’t know if that is possible in the current version).
Keep up the great work and updates.
NS. Can you please add my name to the beta list.
There is the ability to change the file locations of playlist entries via the Ctrl+E dialog though the library playlists never got the browse option that the main playlist editor got (via additions from the JTFE plug-in). But that (like the main playlist editor) requires to do it an entry at a time which isn’t helpful if everything has changed so there’s definitely room for improvement. So some means of batch editing the paths is needed, is just how to make that work easily for large numbers of files or multiple locations.
There’s also the issue of if the playlist itself has been moved (more of an issue if using the real playlist and not a managed copy of the playlist) and a similar solution will need to be made to help make it easier to edit that location (even if as a basic starting point it’s just allowing for a single edit like in the playlists view).
For the next point about missing files, I already intend to provide a missing files option (much like I’ve done on the main playlist editor via the JTFE plug-in) so you can see more clearly which files are missing. Making it easier to find a file to use if it’s broken is a good suggestion but will need a bit more thought. As the obvious thing to do as a starting point would be for the Ctrl+E and Ctrl+F actions to open into the folder indicated by the path if the file is found to be missing so at least you’ve got a reasonable place to start with. But it definitely needs more thinking about how best to handle it all.
For the final point, as I’m going to be mirroring most of what the native plug-in provides for the initial implementation, there is an add / + button on the playlist view that allows for adding files, folders or urls which includes custom entries (e.g. separator:// entries). I hope that’s what you’re meaning.
Definitely a good handful of suggestions and things I’ll need to have a think about on how to make them work (particularly how to go about fixing broken playlist entries which I know is a pain even with tools like listfix), so thank you.
Hi DrO,
We never discussed before, but I’ve been following your work for many years, and I’m really enthousiastic about it!
My suggestion is quite off topic, but I don’t know were else to post it, so here it goes:
Library is the big part that doesn’t work well with wine on MacOS X. As I’m currently using it, and couldn’t find any good replacement for Winamp, I have to use a Windows VM, which is not very convenient. I would love if you could find a way to have it work with wine. I don’t have many hopes about it, but, maybe…
Anyway, thanks for all that great stuff!
Winamp on WINE is a bit funky at the best of times (window placement issues, problems with skinned scrollbars and a few other things iirc) so I’m not too surprised to hear that there’s problems with it on a OS X setup.
It really depends on what the issues are as to whether this is anything that can be (easily) done or not. As some of the things that I know off can be fixed but requires either re-implementing or at least just patching out to disable the troublesome code.
So if you can detail what the issues are (either here or can drop me an email if that’s easier) and I can then at least comment on what might be able to be done or to give it some consideration on how it might be possible to resolve. Though really if running it under WINE is causing issues then that’s more of an issue with how WINE is or rather isn’t doing things that work natively on Windows but that’s easier said than done to get WINE fixed :)
My ideas would obviously go for the visual side of things.. and I could go on forever.. so I guess I could just point out (everyone actually) to Dopamine’s visual solutions for Playlist and that would be sort of enough.. =). >> http://orig14.deviantart.net/c4d2/f/2016/203/f/5/dopamine_by_victhor-dab0bk6.png
Some nice ideas there, specially from the visual and un-cluttered aspect in general.. some stuff Winamp could use.. http://www.digimezzo.com/software/dopamine/
From a quick look, the first link is a bit like the local library album art based views but with it making better usage of the available width instead of it all being crammed on the left-side of the item and loads of dead space on the right.
I do agree that there’s aspects of Winamp that need to be tweaked to make them visually more pleasing but also to better make use of the screen space available or just to hide lesser used aspects (like was done with the grouping of the play / enqueue buttons in the library views for 5.66x).
The only issue I see is how to improve certain things when sadly aspects of the skin engines (classic and modern) somewhat force certain behaviours with the visual and usability side of things (e.g. non-scaling frames for classic skins or arbitrary double-sizing on some windows which doesn’t work too well on modern high resolution displays).
Definitely gives some food for thought, thanks!