For those who’ve been following things on here during the last week and on the Winamp Enthusiasts group then you’ll know already one of the things I’ll be covering in this update. So onto this weeks update…
To start with I’ll get the negative side of things out of the way first. Two weeks back I’d mentioned that I’d been looking into but hadn’t made a final decision on providing a WASAPI output plug-in as part of WACUP and that I’d reached out to the author of the YASAPI plug-in to see whether patches for it would be accepted or if it would need to be forked if I wanted any of the changes I’d talked about being included..
When I’d first posted about the plug-in I hadn’t had a reply from the plug-in author but I now have after sending another message on Thursday (7th) and the response that I got back was that patches were not welcome (which seems at odds with the principals with providing an open source plug-in imho) and that I should only have attempted contact via the Winamp forums (which I’m not allowed to post on as I’d explained in my response to the reply I’d received which indicated that replies had been made on the forums which I’m not going to look at) and so have clearly annoyed the plug-in author which was not my intention.
Due to the response I’ve received, I’m now at odds on what to do regarding providing a version of this output plug-in or not. As I have no issue in following the GPLv3 requirements (as I could just have forked it and made any changes I like as long as the code is provided without attempting to contact the original author) nor that there is no implied support, etc from the original plug-in author.
I’m saddened to have received such a response when there’s not many people doing things for Winamp and I’d have thought that where possible trying to collaborate and improve such plug-ins would be welcome but that seems to not be the case in this instance *shrugs*
Moving onto more happier things, my replacement podcast plug-in is about done and I’m just going over some extra testing with it to make sure I’ve not missed anything when migrating the settings from what the native plug-in requires (e.g. what’s stored in the rss.xml and feeds.xml files) to ensuring that things work at the expected time (e.g. scheduled updates of the stored feeds).
So far I’m happy with how it’s looking as I’ve not lost any settings files since getting my replacement working though there are a few small quirks that I’ve found that come from longer running times that need to be sorted out (which is why I’m taking my time to let things just run for better testing).
Now onto the main topic of this update and that’s library playlists and what should be done about them to make them better to use within a replacement plug-in as the native plug-in’s handling is liked in the same way as marmite I’ve found over the years :)
I posted a few days back looking for some input on ideas of how to make library playlists better (see here for the post) and although feedback has been light, what has been mentioned has been brilliant (especially from Juanus who as a 700+ library playlist user is pushing the native library playlist plug-in when it comes to usability).
The first thing that came up in addition to what I’d posted (with customisation of the playlist views to show more information as the main thing) is better search options within specific playlists as well as being able to search within all of the playlists (e.g. similar to the local library search being able to look at all of the media in the library).
The next thing is making the root library playlists node be useful for viewing and managing the library playlists which can be done with something like the following mock-up (which doesn’t include the search functionality that would be present in a final version):
This allows for seeing all of the library playlists in the same view (as is already possible) but with the addition of the right pane it’s then possible to view / manage playlists without having to go to another view that just shows the playlist (as the native plug-in works due to the root + child setup).
Additionally by not having to change library views to look at the playlists, adding all of the playlists as children of the root library playlist node becomes redundant and so doesn’t need to be done (though I’ll most likely provide a means to emulate that behaviour).
That also has the potential to reduce the overall Winamp loading time (more so when you’ve got a large number of library playlists) and reducing memory usage (as the library doesn’t need to maintain as many items) as well as reducing the clutter in the library navigation tree.
Due to all of the playlists stuff above, I’ve since started on looking into ml_playlists.dll (library plug-in) and playlist.w5s (core read / write service) replacements so that I can get a basis up and running sooner rather than later.
From initial research it seems like I’m going to have to make a replacement playlist.w5s in addition to ml_playlists.dll due to wanting to expand on some of the playlist functionality (e.g. additional sorting aspects) which I could hack in but as I also want to have at least XSPF writing added (which there isn’t an existing API in playlist.w5s to do that), it’s just going to be simpler for the long term to have a replacement than trying to patch / hack things on for those parts.
So I think we can now expect the next few updates to be more playlist related. However once I’ve got at least a comparable basis to the native functionality then I’ll be looking to focus on finishing off anything that’s almost done and will be doing my best on getting the first beta build ready for testing (which is going to miss the 6 month deadline I’d been working against by a few weeks).