WACUP Development Update March 2022 (Patreon)

Not sure how this update is going to come out as it hasn't been the best of months with no beta build though there's been a lot of testing including some who've been running interim builds to help validate & resolve some specific & at times long running issues that have been affecting them & some others which as we'll find out a bit more have been put to bed at last.

There's also been the 'fun' of "winamp" coming out with their NFT fuelled future which had been expected for a number of months but is sad to see it finally happen. Not that it really matters for WACUP as I keep plugging away at making it less reliant on the Winamp 5.666 files to work.

So lets get on with this months update & I figure out if I was productive or not other than finally (almost 7yrs in the waiting) getting unfollowed by Winamp's twitter account & them deleting some FB comments from me which weirdly improved a crap day I'd been having...

-

Going back over the approx 125 line changelog between the current dev build & the beta build 10456 there's actually a decent mix of added, changed & fixed entries though some don't convey how much work has gone into them (which are attached below).

-

One notable one which took a few days to resolve goes back around 6 years to my initial work on making an updated WACUP build of the NDE engine (based on older code than 5.666 was using) that Winamp used primarily for its local library & history database files.

The issue with it that finally was tracked down after having resolved a different issue related to the local library view cache handling (that's only been an issue for around half a year in the replacement ml_ll plug-in) was when trying to use it to save multiple unrelated db files at the same time (i.e. playback history & local library changes) where it would then crash &/or corrupt the saved file.

This stemmed from missing that there were a few global variables involved as part of the threaded handling being used & by having multiple things try to use it at the same time it could enter an invalid state leading to issues. As of this update, I've still a change indirectly related to this issue with the history plug-in where it needs some additional changes to better manage how it deals with it's internal asynchronous updates so it doesn't clash with itself & in-turn crash (thankfully not due to the NDE issue but an internal deadlock in the plug-in).

-

Another area that I've been trying to improve upon especially after resolving the NDE handling issue is removing as many slow / long running actions that may happen on the main UI thread (essentially the main program loop & the main window if using a classic skin - modern skins make this a bit messy on what's actually the real main window unlike classic skins).

This is something that's important for WACUP as it helps prevent the OS thinking that something has hung when it's just slow to complete & often this is done by moving things to happen on a background thread instead of doing it there & then (synchronously).

Compared to Winamp, it would do a bit of this but a lot of it was done in-order & that somewhat stems from Winamp's origins from single-core machines & the other is just a bit of laziness &/or not wanting to change what "mostly works" (if you look at forums, etc you can find that this was causing issues for a long time where things would just seem to hang before suddenly responding after the action completed).

With the hardware we're now using, having WACUP relying more upon creating & using multiple threads (not the same as multi-core as even Winamp was multi-threaded but wasn't making use of multi-core unless the OS/platform was moving things around for it) is imho a good thing & if it ends up meaning less issues with hangs / unresponsive but with some pain to get it working correctly via interim / beta builds then it's hopefully seen to be worth doing.

-

Looking at other things in the changelog, just one from today which is more surprising it's not been causing more issues with the beta builds was first reported against WINE but I then replicated it on a Windows 7 VM (sometimes the old tech has it's place ;) ) where media library views may not create. This turned out to be a somewhat dumb programming issue but it was at least fixed.

This overall took about a day on/off looking into it to get it resolved & that's something which really sums up how a lot of March has gone with not as much productive coding as I'd like (nor those still waiting for a new preview build) with a number of issues now fixed often eating up 1 or more days to get things resolved.

Now I could just keep it on the todo list & never bother (sadly something that happened all too often against Winamp when it had a number of people to work on it) or I just suck it up, delay things but end up with what should eventually be a much better & especially more stable WACUP build. However as it's primarily just me & I'm the one also responsible for dealing with crash reports, etc it does make sense irrespective of how grumpy I might get that issues especially those affecting stability are resolved.

This has gotten easier as I move WACUP away from the need for the Winamp core & other aspects but there's still things I know I need to improve & learn how to improve how I do debugging as too many crash reports still don't make sense to me & I'm sure they must have more than enough information present to assist in getting crashes fixed sooner rather than some dragging on for so long as some have.

-

Nearing the end, there's been some useful new additions with more file formats that contain multiple sub-songs in them (e.g. MOD) now being treated as mini playlists which makes it much easier to just see & interact with those sub-songs instead of just it showing as one big file.

Other things include finally having sort indicators on the media library listview headers so it's possible to see the column being sorted by along with the direction & is something that's been missing since I dropped the Winamp gen_ml plug-in for the WACUP media library core & the shared skinning implementation that came along with it.

The main visual difference with this addition (or just getting implemented what's expected) is that it uses unicode block up/down arrows so it can be nicely scaled to match the text font unlike Winamp's implementation which used a fixed size image & made no attempt to scale it as needed causing it to look silly when using large text in the library views.

The other set of related changes I want to note has been doing some work to get some more of the incomplete features with the x64 test build resolved which mostly related to the classic skin main window visualisation & picking a FFT implementation that works for it but can also be used for the x86 build allowing the janky re-use of a supporting Winamp dll to be lessened.

There is still the big issue of a few key formats not working with the x64 test build & those will come as I did briefly start on an in_mp3 replacement but then got side tracked fixing issues with the builds. From the testing that's been done so far against it along with the normal x86 fixes, the next set of beta builds should be in a much better place (I know I say that a lot but the overall direction has been going the right way which is all I can aim for).

Also over time there's going to be more distinction between the x86 & x64 builds but for now it's mostly one having less features & a few visual differences on the about dialogs (with the nod to the old Winamp as a replacement for one of the expected easter eggs), etc.

-

One thing that I almost forgot about is something that came up a few times in March & that was seeing a few users enabling Mandatory ASLR on Windows 10/11 & watching WACUP not be able to run unless it's set to run in non-legacy mode (good thing I got that working not too long back!).

One of the changes related to what I've done can be seen in the images for this post where the WACUP core will now do some basic checking to see if it's been enabled or not & if it has when using WACUP in legacy mode (i.e. having to use the winamp.original process to get loaded) it'll show that message & abort instead of a random OS provided error message appearing.

This is one of the numerous reasons why I've been trying to get WACUP away from using the Winamp core exe to get it loaded despite dislike of the idea from some who don't get what WACUP is trying to become.

As such this is something where patching the original Winamp process won't really help & my earlier attempts actually broke a load of things as that exe was never compiled to be compatible with the setting which can help improve per-process security (I know it's not a 100% solution but it's better than doing nothing as I understand it).

I do think there's going to be a time where more are likely to have Mandatory ASLR enabled & it's going to cause issues with a lot of older programs including old Winamp versions & hopefully enough collective knowledge will exist by then for those still wanting the classic winamp experience to at least consider WACUP as an option when their classic Winamp install won't work.

Though as the mid-month "winamp" NFT / foundation announcement sadly showed, a lot just ditched their Winamp installs on principal & things which are associated in whatever way with the brand & overall ecosystem are now seen as being tainted by them even if I'm not into NFT's & is not a route I would go with WACUP. The main thing is that WACUP will behave with that non-default OS setting being applied & that's better than not being able to load at all imho.

-

Probably a bit more of a rambling update than even my normal standard so I'd better stop now plus I need some sleep as it's been a long day & I wanted to get this one before stopping for the day (even if its now posting technically as the first day of april - no foolish things from me today other than this blurb!).

So hopefully a new beta will finally be ready in the next few days once the ml_history re-work is finished & then I can get back on with the blocking issues that are holding back a new public preview build.

As some of you know from Discord I did finally start on the in-view artwork aspect but I'm not happy with the solution I'd been playing with so that's not going to be part of the new beta build but at least instead of keeping it all in my head it's now starting to appear as tangible code :)

-

Until the next update which should be for a new beta build, thanks for the continued support allowing me to keep doing this & stay safe.

-dro