Last week I noted that it’s now summer time here in the UK and true to form, the weather hasn’t been all that great which means it must be true especially as it was time for Glastonbury and it’s notorious mud-baths - which does not appeal to me one iota. On a related note (fnarff), for those who get_iplayer access then there’s a good range of full sets from this year’s Glastonbury which should have something for most to enjoy (alas not officially within Winamp ;) ).

Now onto what happened during the week…

---

To start with, the work for splitting out things from the JTFE plug-in and it’s related re-organisation is progressing albeit slowly due to some of the distractions that will be covered later. The main aspect was getting the final parts of the elevation / UAC functionality replacement finished off which will now ignore the original elevator.exe + elevatorps.dll implementation for a /ELEVATE mode in the loader + a light-weight elevate.dll.

---

The next smaller change was an unreleased update for the Album Art Viewer (gen_classicart.dll) plug-in which makes it a bit smarter in its resource usage to clear the artwork file cache if the window is not visible which seems reasonable to do if it’s not visible. This can save up to a few MB of RAM depending on the artwork associated with the playing / selected item

---

The next thing involved looking into how Skype for Windows allows for external programs to set the mood value (which was based on something I’d seen mentioned on twitter about some Winamp plug-ins not doing it anymore or not doing it correctly). After a bit of digging I’ve managed to find the details of what needs to be done to hopefully do this from a plug-in.

Why look into this… because one of the eventual aims is to have (yet another) now playing (spammer) plug-in as it’s just one of those things that people keep using. Plus having something that properly does unicode / UTF-8 and can leverage the information which Winamp can obtain as well as being able to work with the services that are now used is not quite there (imho) with the older options already out there.

---

Something that I’ve been looking into but haven’t made a final decision on is providing a WASAPI output plug-in. Whether this is better or not is hard to say (as most of the audio output options like DirectSound are effectively built on top of the WASAPI base platform) but it’s more about providing a range of choice for what people want.

There have been a number of such plug-ins to differing levels of success with the best having been the Maiko plug-in but as this now appears to be abandoned and no obvious means to contact the plug-in’s author, the new comer YASAPI appears to be taking on the role of the best WASAPI output plug-in implementation available.

It is a plug-in that is under development (having seen a number of new releases in the few days since I’ve been actively looking at it) and the source code is available (though am hesitant about considering a GPL based plug-in) which does mean I could look at improving some of the Winamp integration (e.g. localisation, 5.66+ improvements) but it may end up as a separate fork depending on any potential changes I make being accepted or not (am waiting a few more days before I re-contact the author from my initial message as I’d prefer to get an ok rather than blindly following the GPL)..

---

And finally, as some may have already seen on twitter, I posted the following before the end of the week:

grr #winamp's podcast support has corrupted its settings files for me yet again! well no more! replacement plug-in will have to be started.

— Darren Owen (@The_DoctorO) June 24, 2016

The result of that tweet (and is something that I’d intended on looking at anyway) is starting on a replacement ml_wire plug-in. As something that I do use despite some of it’s quirks, having the settings files get corrupted again (which thankfully, I’d got a recent backup from the day before that I could revert back to) was the final straw.

I had looked at back in 2014 about what might be needed for a replacement for this native plug-in and the following is a quick mock-up of two visual changes I’m contemplating in my replacement (so when it does get implemented it may end up changing from what I’m showing now)..

The first change is in the info area to include the branding image for the feed as it’s a bit quicker to see what’s the current selection and it’s simple enough to modify the simple HTML that needs to go into the feed to do it (and I think it looks nicer, heh).

The second change is to have the feed list take the full height of the view instead of only half the height, with the space taken from the info pane which then becomes half-width (though I’d likely add a means to emulate the original layout if wanted). Doing this makes it easier to see more of the entries in the feed which the original layout compromises if you don’t want to have a large library window (insert lame comment about VGA screen resolutions).

On implementation aspects, I never liked (once I’d found out what the native plug-in was doing) is how it loads everything on start-up even if it’s not desired to do so just to check a few values to see if it needs to do an update on start-up. I get why this was done but it’s not helpful for fast loading times nor only using the resources that are actually needed.

For reference with my current list of feeds, this behaviour equates to almost 20MB of RAM being used for no real reason with my setup using around 60MB of RAM depending on what I’ve got loaded as the current file and the skin (it goes up to around 90MB if using the Big Bento skin due to allow of the images and everything else the modern skin engine does).

---

So that’s it for this update. The next few days are likely to stay focused on the podcast plug-in replacement whilst I work out what’s needed for it as I want something that works reliably and I have to be brutally honest that the native plug-in doesn’t achieve that for me.

-dro