Latest WACUP public preview for x86 & x64 is build #25130 (September 30th 2026) (x86 & x64 changelogs)
Latest restricted WACUP beta release is build #25130 (September 30th 2026) (x86 & x64 changelogs)

Recent Posts

Pages: [1] 2 3 ... 10
1
You could try turning off the title update aspect otherwise it's just how much longer am I going to take to get the preview build updated to see if that does help resolve all of the dsp_wc issues or not.
2
Well, I've been using 25130 for a week and cpu issue is still here in this room
3
As a follow-up to this it's been found the plug-in in build 25130 isn't correctly processing title updates in SCv1/Icecast mode due to the changes that were made to try to resolve the high cpu issue (some appear but it can build-up a list of pending title updates) which can still cause some cpu load issues. The complete fix needed to get titles working & keeping the cpu load down requires a new build (out later this month) instead of being able to be done via the post-release updates.
4
Visualisations / Re: superbounce!'s 10 Presets Pack
« Last post by superbounce!2 on Today at 12:39:37 PM »
hello i wanted to tell you that i lost acces to my email assigned to my old account and no i am not a fake account im the real account
5
Preview Build Discussion / Re: [FIXED] Problems with Jump to File
« Last post by GatorMan on Yesterday at 02:56:52 PM »
Wow thank you all so much, you rock! I only just found WACUP a few weeks ago after using Winamp for, well, decades. WACUP is like a breath of fresh air. Thanks again 🙏
6
Preview Build Discussion / Re: Icons.....not changing?
« Last post by dro on Yesterday at 02:39:47 PM »
If that or any other player better suits your needs then you should just use that. I'm not too bothered about implementing file association management into wacup as that's not something I need & I'm fine if that irks others which is why it's noted there's no file association options during install, etc.

I've not removed it & since wacup hasn't relied on the winamp core to load / run for a long time now it's not comparable to what what winamp had offered with its icon packs which was only happening from me hacking things in with my jtfe plug-in against what the winamp core & it's file association prefs page. There's nothing to stop you / others manually editing the OS file association details in the registry to achieve the same effect of per-file icons.

It's however something that I'm aware I've got to consider having when I finally do get around to implementing things but I've no near term goals to do that & there's things about the old style of icon packs that I never liked which I'd likely do differently anyway. I will move this into the wishlist sub-forum in the next few days.
7
Preview Build Discussion / Re: Icons.....not changing?
« Last post by Killjoy on Yesterday at 02:22:30 PM »
So, you excluded an option to change file explorer icons? Aw... :-[
Too bad. Can we hope that one day....icons could be changed?

I mean, I've got a LOT of FLAC, WAVE, MP3 and other various audio files....and it would be great if we could see them different?

AIMP did that pretty good. FLAC icons are green, MP3 are red....etc....
8
in_url wasn't meant to be taking anything that's not a [http|https]:// like url but an internal api change some time back meant it was taking anything that's :// without knowing it.

Due to the order in which the input plug-ins are loaded (there are no options to control this nor will changing the filenames help) & thus queried it means the wacup plug-ins are usually processed before any 3rd party plug-ins & in this case in_url was incorrectly claiming things preventing any other plug-ins yet to be queried as part of the "find the plug-in to use" loop. This is the inherent downside of winamp's isourfile(..) method being a first match gets it which is why I generally try to avoid using that method when it comes to wacup's implementation of the plug-in handling but for url like options it's basically the only way to do things.

I've now got things changed in in_url for the next build so it'll limit what it's trying to claim to just [http|https]://.

For aiding in debugging, prefs -> about|updates -> about tab has a box at the bottom which will show what the active input & output plug-in are to know what is trying to be used though the alt+3 dialog for url like options is also a way to figure it out.
9
Preview Build Discussion / Re: [BUG] ATF: can't $replace with empty string anymore
« Last post by dro on Yesterday at 09:59:52 AM »
That's useful to know the $cut from the end of the string changes from the prior build that ironically introduced this $replace problem helps.
10
Preview Build Discussion / Re: [FIXED] Problems with Jump to File
« Last post by dro on Yesterday at 09:58:48 AM »
I've added a workaround when using a modern skin for the next build but I'm not happy with the change as it shouldn't be needed & I'm not finding an obvious reason why the keyboard navigation isn't working correctly in that mode (this might be why I'd had the code in before which led to the initial set of issues in the thread) vs it behaving when running as a classic skin.
Pages: [1] 2 3 ... 10