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).
-dro
Hi DrO.
I’m puzzled by your statement: “the Winamp forums (which I’m not allowed to post on…”.
This is further evidence of Radionomy’s mishandling of Winamp.
Rather than preventing you from posting, they should be begging you to participate!
You are still on the Member’s List and “banned” is not displayed in the member information panel of your posts.
Many people on the forums believe that you have chosen to refrain from posting, not that you have been prevented.
Have you been prevented from posting since your last post on May 6, 2016, perhaps in a way that cannot be seen by others?
You’re correct in that my account isn’t banned (as I naively did back in May - I’ve since deleted my account password so it’s harder to drunkenly post again) but to an extent it is me refraining from posting there as I don’t feel happy contributing to something that is run by certain people who don’t appear to care. I know that’s not great and doesn’t help with the community aspect but it’s how it seems it has to be.
The reason for that is because management never replied to me when I was let go when I tried to get clarification on things (i.e. if I were to continue contributing to the community then if that was welcome or not on their forums) and so I’ve got to interpret that lack of reply as meaning I’m not welcome to contribute there.
Plus as I’d been associated too much by the end with SHOUTcast support (I’m still seeing PM notifications come in every now and then) and I know if I was still posting on there that I’d probably end up helping out on that (which is needed based on the lack of responses to a lot of posts that I saw when I gave in and posted in May) but that’s not how it should be if they’ve got dedicated support people.
So that’s why I’ve worded things as I have since it’s simpler and basically summarises how things are. Either way, what’s happened has happened and I’d prefer to not dwell on it and do something positive unlike RN.
The wording may be simpler, but the meaning is not the same.
“not welcome” does not equate to “not allowed”.
I have no respect for Radionomy and the way they have treated employees and Winamp users, but you have implied that you were blocked from posting on the Winamp forums and that is not true.
I’m just trying to clarify the situation because your statements here have been quoted on the forums.
The end result is the same in my view point and it has not been my intention to mislead in how I’ve worded things as the (lack of) response from RN is how it’s felt to me (hence my usage of ‘not allowed’ as asking and getting nothing back to my interpretation of things implies a no). Now you’ve pointed it out, my wording of things probably should have been clearer (is the problem when emotions are involved) but what’s done is done (especially as I’ve used ‘welcome’ when I previously talked about such matters on https://getwacup.com/blog/index.php/2016/04/05/week-10/).
Either way, both parties (RN and myself) have made decisions regarding Winamp and each sides respective involvement with it and I’d really like to draw a line under things as there’s too much negativity around Winamp and maybe I’ve unintentionally fuelled some of that myself due to the emotions involved which I’ve been trying to do my best not to be part off and instead focus on the positives and what can be done. It sounds like I’m still failing badly at doing that and that’s not what I want to be known for :(
As for people quoting things I’ve said, then so be it (I appreciate that you’ve taken the time to ask about things) as there’s nothing I can do to stop that from happening nor how such comments may have been interpreted or commented on.
Hi Dro, are you planning to include Asio built-in plugin support?
It’s not something I’m planning on providing. Other than a null output plug-in and some form of WASAPI output plug-in and possibly providing an easier output plug-in switcher, I’ve not really got much planned when it comes to output methods.
Would be nice if someday you add some support for ASIO or Wasapi output. But I guess it needs a lot of work, so it will not be so fast, if ever :P
Ps: I suggest to not support/use/fork pbelkner’s Wasapi plugin (YASAPI). The guy is strange and for sure not interested. He is also known as best programmer all over the world, so… don’t even try :)
WASAPI would be the more useful since it should work on all versions of Windows that will be supported (i.e. Win7 and newer) which unless I’m wrong (which is likely without checking) is not the case for ASIO without specific driver support.
As for that plug-in, whatever I do now be it a fork (as is all fine under the license terms but is not at all what I wanted to see) or having nothing to do with it and start from scratch from the MSDN examples / documentation, I’m expecting (based on other comments I’ve been told about what’s been going on elsewhere) that accusations would be made in-addition to the ones that have already been made.
So maybe it’s just better to just bite the bullet, fork it as others (based on feedback I’ve received) want things implemented that the author rightfully doesn’t want to do and which the license that the author has decided to release things under allows.