The x86 build of wacup has support for all types of winamp skins (classic/winamp3/5.x) as long as the needed winamp plug-in is installed for the modern ones whereas the x64 build (per the download page & install notes) only supports classic skins. There's also the provided skin scaling modes to use.

I'd already suggested it in the forum thread with the caveat that I've not tried this software out. Though the freeze mode was more aimed at avoiding user interactions messing things up & if the OS wants the screw around then it will. I also suspect the off-screen handling is causing problems here.

this should be fixed for the next build. I wasn't checking the available height of the provided image element vs the default that's expected which meant the call used to copy the image data over failed as it couldn't copy more than wasn't available (e.g. 6px block instead of the expected 11px block)

to answer something else, the 64-bit of wacup doesn't support modern skins because I've still to start making a replacement plug-in that would allow it to be able to support those skins. as wacup 32-bit only supports it due to being able to fiddle the gen_ff plug-in to get it work outside of winamp.

it is a bug that should've been reported & is from me trying to make wacup work more like webamp for some of the classic skin elements so transparency if provided in the skins is used.

I'm trying to replicate it not reacting when stopped but I don't seem to be seeing that (sliders move & ui updates) unless I'm missing something &/or the device(s) used are behaving differently to what I can test with. At least it seems to be working more reliably using it which is the main thing.

Ok. I can't remember if the plug-in needed to use some of the dlls from apple to do it's thing or if it was self contained to just the older way & being locked out which limited device support.

I've put up a newer build which should be better behaved with the process volume vs default device changing & also with the config handling which the 234xx builds broke causing various loading issues which is likely behind the issue you were having.

it could be from trying to access an api I've not implemented or is doing things that are out of spec or it's a runtime related conflict which also affects the alternate ml_pmp / pmp_ipod option. my plan was to use ml_ipod to replace ml_pmp but I've not got a working ipod I can currently test on it.

It's a newish feature & I wasn't sure if many would even use it so I'm not surprised it's not tracking device changes correctly. I've likely just not hooked up something needed to detect that. Will see what I can do about it before the next build goes up.

Changing to use one of the all-in-one skins might be a better fit.

I've never been memeable nor could I tell if it was taking the p or not out of there not being a non-windows version of wacup.

?

Other beta testers are using it but they don't tend to comment much since it mostly is working or is just tried out as somewhat of a curiosity. There's also a decent number seemingly using it via the preview builds based on the occasional crashes seen.

WACUP via WINE should work & there's been a bunch of changes from the second half of this year for WACUP that should make it be better behaved via it. Though I get for a lot that's not an appropriate solution & native only is the only way to go which isn't something I'm prioritising even attempting.

I've updated the post-release patches with a newer build of the plug-in which should play correctly. Trying with the SF2:CE set I could finally hear it missing the drum parts & noticed the alt+3 / file info wasn't showing the 2 chip cores needed which the lib update broke those cores being included.

ok, I'll have to try again to replicate this. just not sure what I'm missing as to how you're able to hear it consistently unless I'm hearing it with the older builds & just don't know the audio well enough. also still uncertain why the libvgm changes would've broken it in such a manner *confused*

Was WACUP reporting any errors during loading? Am not trying to win you back if something else better suits your needs (am fine with that) & am more concerned seeing comments about it just not working to try to get it resolved for anyone else affected.

I don't seem to see or hear a difference between 22982 & 23234 now mine is loading ok nor can I see a reason from the small changes in libvgm that'd be able to break everything.
What build had you been using that was working ok & was it wacup's plug-in or from one of the external vgm plug-in builds?

Try removing the in_vgm.ini file from the <wacup_settings>\plugins folder. The only thing I can replicate compared to build 22982 is it plays but no audio can be heard / rendered which removing the existing file resolved it for me. Am still trying to work out why my config file is breaking playback.

The plug-in you were using for all of that likely isn't installed or if you were using the nullsoft midi plug-in previously then it's either not been installed (e.g. the 5.666 installer couldn't be obtained) or just needs enabling in the x86 wacup build (prefs -> plug-ins -> input & check in_midi).

The root library node should indicate processing & potentially the files remaining to be processed but I don't have a nice way at the moment to indicate a potential eta especially for network shares. I'll have to look into trying to reduce the import time again as that seems too long vs old builds.

I've put up a post-release fix which should resolve it.
It'll either appear as an OS toast or can be manually got by going to Preferences -> About | Updates -> About tab -> using the update button which should indicate there's updates & allowing it to restart and confirming the copy can be actioned.

Was that involving the current 23234 build & MP3 files? As I've made it use a slower mode to correctly determine the length of them due to too many not reporting it correctly. If it's with older builds then it'll just be from it reading all metadata to cache along with associated artwork dimensions.

Ah that one. I'll a look at changing to use a different variant of the open/save file dialog for one that doesn't have the visual problem (without looking at the code I can't why I'm using that form of it when the one without the left panel is used elsewhere).

Which file prompt specifically? Though anything OS provided messing up is going to be a Windows issue due to them not providing enough native dark mode control support (at least with Win10, can't remember how it is with Win11) & there's parts I've still to work out how to custom draw them to fit in.

are there any specific vgm sets that you've been playing that show this issue? also do I assume they're all from vgmrips?

the vgm library had been updated so until I can look into it I've got to assume it changed something that wasn't conveyed as needing more changes to be made to the plug-in built around it.

There should be a submenu in the main right-click menu that allows for changing it if more than one asp*.txt file is provided.
Under wacup it appears at the bottom but breaks the placement of other options & may also do the same to winamp.
It also requires running as admin to try to save the choice.

Which is why if there's a simple documented spec or I can figure things out from the chm help file that doesn't show it's contents for me currently then from a WACUP stance I'd prefer to just implement support for this classic skin addition natively instead of trying to patch an old plug-in to work.