WACUP - First experiences, bugs, wish list

[Altus]

Hi, I've been using Winamp practically every day since 1998 and version 5.666 has been running for more than 10 years now, even under Windows 11 there are no problems. Well, none except one, Milkdrop no longer runs under Windows 11, which is why I was looking for a solution and found WACUP! So I tried it out straight away and tested it extensively for two days. The good news is that Milkdrop is running again! But I noticed a few problems and bugs and i have some Questions. I also have one thing for the wish list. So let me get started.

>> The thread "Known Reported Public Preview Build Issues " was last updated in January 2019 and nothing can be found at https://getwacup.com/known_issues.html. So it could be that some/all of this is already known.

Problem #1 - Jump to File Box

1) I deactivated the "Skin the window in the current WACUP skin stlye" option in the plugin. But then the "Jump to File Box" can no longer be used properly because the text "Search for Text" is displayed exactly above the input field. You can type without problems but you can't see what you have written. You can use mouse-over to make the overlay disappear, but only until you press the next letter, then everything is covered again.



2) The "Delay from last typing action before the search is processed" option in the plugin is already applied when opening the "Jump to File Box" and not only when typing. I don't know if this is intentional but it seems to be quite useless when opening the box for the first time.

3) When you open the "Jump to File Box", the cursor is normally on the currently playing song. However, both the "Limit the number of search results to be displayed up to..." option and the "Only show search results when a real search has been entered" option prevent this. It would be nice if the cursor would still be on the current song with both options so that you can continue to scroll quickly through the list using the arrow keys.

This might be difficult with the limit option, if you set the limit to 1001, for example, then the cursor would have to be on the song and 500 songs would be listed up and down. But I see no problem with the "Only show Search..." option. If you deactivate both, the box behaves exactly as in Winamp. But setting a limit speeds up a large playlist with 50000+ songs enormously! It would be a shame if you had to sacrifice these two options in order to continue to benefit from "scroll from current song".

Problem #2 - Global Hotkeys Plugin

I was able to create/change all the hotkeys I need. But it took me several attempts. Because from time to time the following error occurred in connection with CTRL+ALT+Something:



Restarting WACUP solved the problem. For some hotkeys I also needed up to three restarts. No big deal and eventually I was able to create them all but I thought I'd report it.

Problem #3 - Playlist m3u/m3u8 Loading

1) If you load a playlist via Play > File (Key L) or via the EJECT button (Open File(s)), the song that is currently playing is written to position 1 in the playlist instead of the song stored in the *.m3u/m3u8 file. Only playing this song will then show the correct name.

2) If the playlist is completely empty and you press stop and then load a *.m3u/m3u8 via Play > File or the EJECT button or the Play button, position 1 also does not show the name of the song but the full path to the file. Again, the song name is only updated when you play it.

>> I have a playlist in which Song 1 is displayed correctly but I could not find out what makes the difference. Possibly the path of the files which sometimes contains special characters like an "&" sign. I saved all playlists again with WACUP but the generated m3u/m3u8 show the same behavior.

In addition, all playlists are loaded correctly (and song 1 is displayed correctly) if you load them using CTRL+O or via the playlist itself. Manage Playlist > Open Playlist.

3) If WACUP is started via *.m3u/m3u8 then Song 1 in the Playlist is always played even if "Playlist Shuffling" is activated. Winamp already selects a random song at startup. Only if WACUP is already running and you then load a playlist will a random song start.  In WACUP Song 1 is always at #1 in the Shuffle Inspector!

4) If the Playlist is completely empty and you press Stop, Winamp 5.666 Build 3516 is displayed in "Windoshade Mode" instead of WACUP v1.9.20.17040 (x86) as in "Normal Mode". 

Problem #4 - Performance

1) I have disabled the media library, video playback and many plugins and yet WACUP uses slightly more CPU than Winamp (even though the load is ridiculously low). While trying to reduce the CPU load to Winamp level I realized what the problem is. In Winamp I can set the "Timers Resolution" in the Modern Skins menu. In WACUP I can only choose between 60fps and 30fps, i.e. between an update of 16.6ms or 33.3ms. But in Winamp I have set 66.6ms which corresponds to 15fps. If I set Winamp to 16.6ms or 33.3ms then the load is similar to WACUP. So I suggest adding a slider like in Winamp or allowing a user-defined value in addition to the 60fps and 30fps. Possibly also only via INI Edit, would be fine with me.



2) Why is the Public Preview release only available in x86 and not in x64? Is the performance better or even worse with x64?


Okay, here's a small request for the wish list:

Feature Request - Extension of the Global Hotkeys plugin

It would be fantastic if you could define more hotkeys in addition to the ones you can already assign. I'm thinking, for example, of " Show Album Art" or the Waveform Seeker. At the moment you have to click on WACUP before ALT+A or ALT+R will work.

That reminds me, is there a way to open "Album Art" and the "Waveform Seeker" via a button in the skin? By action, rightclickaction, dblclickaction, cfgattrib or something else? I would like to build the buttons for this into my skin.

So that's all I've noticed in the two days of testing WACAP. But as I don't use many of the features, I didn't notice any errors there either. However, I tested the internet radios and everything worked as it should. Milkdrop in desktop mode with WACUP is also finally running again And the Waveform Seeker plugin is brilliant! This is what my WACUP looks like now (my Winamp looks exactly the same):



All right, thanks for the cool project. When will the final version be released? Is there a roadmap somewhere or other ways to view the development? A Github page or something similar?

Thanks @dro for the help with the registration!

[dro]

>> The thread "Known Reported Public Preview Build Issues " was last updated in January 2019 and nothing can be found at https://getwacup.com/known_issues.html. So it could be that some/all of this is already known.

That thread / page needs to be started over again which is intended once the next set of preview builds arrive.

Problem #1 - Jump to File Box

1) I deactivated the "Skin the window in the current WACUP skin stlye" option in the plugin. But then the "Jump to File Box" can no longer be used properly because the text "Search for Text" is displayed exactly above the input field. You can type without problems but you can't see what you have written. You can use mouse-over to make the overlay disappear, but only until you press the next letter, then everything is covered again.

Will look into it as that was already meant to have been fixed in relation to some of the dark mode handling changes that broke it in an earlier build.

2) The "Delay from last typing action before the search is processed" option in the plugin is already applied when opening the "Jump to File Box" and not only when typing. I don't know if this is intentional but it seems to be quite useless when opening the box for the first time.

I'd need to look into it as there's things in the plug-in from over 20yrs now that I honestly can't remember why they were implemented or what the intent was meant to be. It being linked to the loading of the dialog does seem wrong.

3) When you open the "Jump to File Box", the cursor is normally on the currently playing song. However, both the "Limit the number of search results to be displayed up to..." option and the "Only show search results when a real search has been entered" option prevent this. It would be nice if the cursor would still be on the current song with both options so that you can continue to scroll quickly through the list using the arrow keys.

This might be difficult with the limit option, if you set the limit to 1001, for example, then the cursor would have to be on the song and 500 songs would be listed up and down. But I see no problem with the "Only show Search..." option. If you deactivate both, the box behaves exactly as in Winamp. But setting a limit speeds up a large playlist with 50000+ songs enormously! It would be a shame if you had to sacrifice these two options in order to continue to benefit from "scroll from current song".

I can't currently replicate the search field not being focused on initial loading under classic or modern skins & whether it's being skinned or not.

Problem #2 - Global Hotkeys Plugin

I was able to create/change all the hotkeys I need. But it took me several attempts. Because from time to time the following error occurred in connection with CTRL+ALT+Something:



Restarting WACUP solved the problem. For some hotkeys I also needed up to three restarts. No big deal and eventually I was able to create them all but I thought I'd report it.

I've never seen that happen before & right now I've not been able to replicate it. Maybe there's some other software running / keyboard driver type stuff that's interfering as the input control for the hotkeys is not fancy so shouldn't be breaking like in the manner shown let alone it requiring multiple process restarts.

Problem #3 - Playlist m3u/m3u8 Loading

1) If you load a playlist via Play > File (Key L) or via the EJECT button (Open File(s)), the song that is currently playing is written to position 1 in the playlist instead of the song stored in the *.m3u/m3u8 file. Only playing this song will then show the correct name.

2) If the playlist is completely empty and you press stop and then load a *.m3u/m3u8 via Play > File or the EJECT button or the Play button, position 1 also does not show the name of the song but the full path to the file. Again, the song name is only updated when you play it.

>> I have a playlist in which Song 1 is displayed correctly but I could not find out what makes the difference. Possibly the path of the files which sometimes contains special characters like an "&" sign. I saved all playlists again with WACUP but the generated m3u/m3u8 show the same behavior.

In addition, all playlists are loaded correctly (and song 1 is displayed correctly) if you load them using CTRL+O or via the playlist itself. Manage Playlist > Open Playlist.

3) If WACUP is started via *.m3u/m3u8 then Song 1 in the Playlist is always played even if "Playlist Shuffling" is activated. Winamp already selects a random song at startup. Only if WACUP is already running and you then load a playlist will a random song start.  In WACUP Song 1 is always at #1 in the Shuffle Inspector!

I've been trying to replicate all 3 of these but so far haven't. I'm either not following things or there's something else going on that I'm missing which maybe is even down to stripping the install back a lot as you've mentioned in another part or maybe if you've got wacup running in legacy mode. With build 17040 that's only needed for having the equaliser work whereas I'm currently on a newer dev build than recent beta 18106 & legacy mode is no more & things afaict work correctly on all counts from what I've been trying. I would also suggest maybe trying the classic base skin to rule out at least the first two being related to the skin being used as there are things that the modern skin engine plug-in does which in some scenarious might be able to cache / display the wrong information until a proper playback event then occurs.

4) If the Playlist is completely empty and you press Stop, Winamp 5.666 Build 3516 is displayed in "Windoshade Mode" instead of WACUP v1.9.20.17040 (x86) as in "Normal Mode". 

That depends on the skin & if it's a modern style of skin then there's limits on my live patching skills to override some of the gen_ff plug-in strings whilst needing to provide that compatible string for other things the gen_ff plug-in needs. So that's why there's going to cases of the winamp version string appearing over the wacup version.

Problem #4 - Performance

1) I have disabled the media library, video playback and many plugins and yet WACUP uses slightly more CPU than Winamp (even though the load is ridiculously low). While trying to reduce the CPU load to Winamp level I realized what the problem is. In Winamp I can set the "Timers Resolution" in the Modern Skins menu. In WACUP I can only choose between 60fps and 30fps, i.e. between an update of 16.6ms or 33.3ms. But in Winamp I have set 66.6ms which corresponds to 15fps. If I set Winamp to 16.6ms or 33.3ms then the load is similar to WACUP. So I suggest adding a slider like in Winamp or allowing a user-defined value in addition to the 60fps and 30fps. Possibly also only via INI Edit, would be fine with me.

This is one that I'm not going to modify over what is provided. The whole script timer aspect had to be taken over by WACUP code to be able to use gen_ff under it without needing the Winamp core program & the way the old slider worked just wasn't worth the effort on my part to try to figure out how to hook into the studio.xnf settings handling without making other aspects suck & didn't see it being worth the effort. That's why my handling ended up as just a basic high/low toggle & I always knew that it was never going to be the best fit for some but it's the choice I've made.

I appreciate that it makes modern skins use more resources & cpu time but it also better matches to the common screen refresh rate & reduced a number of visual issues seen due to quirks in timing. Tbqh the whole timer thing is something that imho shouldn't even have to exist but that's a gen_ff design limitation & the aim is to hopefully end up with a gen_ff replacement that can do all that's needed without such hacky config options.

2) Why is the Public Preview release only available in x86 and not in x64? Is the performance better or even worse with x64?

The x64 build is not yet at feature parity to the x86 build & was mostly for my internal needs to be able to compare on how close an all native wacup implementation vs the various stages of the normal x86 wacup + re-using some of the exe/dll from 5.666 was.

It also doesn't support any 3rd party plug-ins, no modern skins as gen_ff can't be loaded & there's no native replacement plug-in for that & bunch of other things. Performance is effectively no different between them but at times it feels a bit more sluggish to me though the profiling numbers don't seem to indicate that. The only real benefit is there's more process address space for large local library databases & large image files to work within that under the x86 build could fail due to running out of available process memory to work with.

When I'm in a position to support it at a wider level & it's at parity for the most part sans things are not going to be done with it (i.e. it's not going to be opened up to allowing 3rd plug-ins for an unknown amount of time when it does get publicly released) then it'll be made available. I get that native is seen as being better but I also need to ensure that I'm not going to get a flood of "this plug-in don't work" complaints when that's most likely what's going to happen due to how it seems to go.

Okay, here's a small request for the wish list:

Feature Request - Extension of the Global Hotkeys plugin

It would be fantastic if you could define more hotkeys in addition to the ones you can already assign. I'm thinking, for example, of " Show Album Art" or the Waveform Seeker. At the moment you have to click on WACUP before ALT+A or ALT+R will work.

I've added it to the todo list as something to consider. As a generic way to have any of the currently available skinned windows being registered would be the nicer way vs having to do too much on per plug-in customisation to get things implemented as would be the case now.

That reminds me, is there a way to open "Album Art" and the "Waveform Seeker" via a button in the skin? By action, rightclickaction, dblclickaction, cfgattrib or something else? I would like to build the buttons for this into my skin.

Possibly if it was coded into the skin (looks like one of the bento based ones from the screenshot) but my maki knowledge is slim so I don't have an easy suggestion on how best to try to achieve this.

When will the final version be released? Is there a roadmap somewhere or other ways to view the development? A Github page or something similar?

I've no eta on when a final will be done & it mostly comes down to when everything that's needed to be at feature parity or better is done along with ideally no or at least the very minimal need to re-use any of the dlls from 5.666 along with shell integration & localisation support. Then there's whatever distractions & oh look a squirrel moment I have working on things. So no, there's no formal roadmap & based on my prior attempts at something like it, they never worked out as planned so I decided not to bother doing them & waste mine & others time doing them. The build changelogs, odd stuff when I remember to post or what I'm talking about on the discord server are the main ways to follow what's going on.

I think that's everything answered, now I've got at least some bugs to try to resolve from this.

-dro

[Altus]

Hi and thank you for answering!

Playlist m3u/m3u8 Loading

I've been trying to replicate all 3 of these but so far haven't. I'm either not following things or there's something else going on that I'm missing which maybe is even down to stripping the install back a lot as you've mentioned in another part or maybe if you've got wacup running in legacy mode.

Okay, I have created three new test playlists and tested everything again. WACUP runs in portable mode (thanks for that by the way!) and also not in legacy mode. And for the following tests I used the Classic base skin. The skin I usually use is called "Winamp Modern" and is installed with WACUP (full install).

In the animation you can see the following: "Metallica - Lux Æterna" is currently playing. Now I load the Lindemann playlist. As you can see, "Lux Æterna" by Metallica is now at position 1 in the playlist. When I play this (by double-clicking), the playlist is updated with the Lindemann song. Next I select "Lindemann - Knebel" and then load the Metallica playlist again. And now "Knebel" by Lindemann is in position 1 and not "72 Seasons" by Metallica as saved in the playlist. This also works with the PLAY button and not just with the EJECT button.



The following happens in the next animation: "Metallica - Lux Æterna" is playing again. I press STOP and clear the current playlist (CTRL+N). Then I load the Lindemann playlist and instead of seeing the Lindemann song at position 1, I see the path of the file. Here as well: only playing the song updates it in the playlist. This also works with PLAY and EJECT.



Regarding the problem with the missing shuffle at the start, I don't know exactly what I should do wrong there. I have a test playlist with 1200 songs. I save this as an m3u8 file. When I quit WACUP and start the playlist, WACUP starts and song 1 is always playing and never another one. The Shuffle Inspector confirms this. By the way, I have deactivated "Preserve shuffle table between sessions". However, activating it does not change the behavior.




Jump to File Box

I can't currently replicate the search field not being focused on initial loading under classic or modern skins & whether it's being skinned or not.

There are new findings regarding the problems with the "Jump to File" box. I was able to narrow down the problem.

First of all, here is an animation of the "Jump to File" box without a limit. I start at song 500 of 1200. Then I open the box and can scroll easily using the arrow keys. That's how it should be.



Here is the animation of what happens when you set a limit (100 in the example). I start again at song 500 of 1200. As you can see, the cursor starts at song 1 and not at song 500 as before.

However, I have just found out that the cursor does start at song 500 if the limit is higher (or equally high) than the song in the playlist. In this example, the limit must be exactly 500. However, I can't scroll any further down because then only songs 1 to 500 are displayed. With a playlist of 20000 songs as an example, I can never know where the song I'm looking for will be, so setting a limit is useless if I don't want to do without fast scrolling, otherwise I risk the song being higher in the playlist than my set limit.



If this option is activated, nothing is displayed at all. However, this could be intentional in this case. Although I would have expected it to start with the current song anyway.




Performance

That's why my handling ended up as just a basic high/low toggle & I always knew that it was never going to be the best fit for some but it's the choice I've made.

And a High/Low/VeryLow (60/30/15fps) Toggle is not an option? Well, as I said, the CPU load is very low, but it is higher than under Winamp. However, I had no idea that there was so much more going on under the hood. I can only really see it in the scrolling song ticker and the spectrum analyzer.

About x64: Okay, I wasn't aware of that, I "just discovered" WACUP you could say. But good to know.

Okay then, thank you for taking the time to answer me 

[dro]

1) I've made some changes for the next build that may or may not help as there's a possible issue with the shuffle table vs quick playlist changes along with getting metadata from the local library which could possibly explain what's being seen. What's directly shown I'm still not experiencing it hence my caution on saying it's fixed.

2) If the current song's playlist position isn't within the limit range then it's not going to be shown so it can't be selected & is why it then defaults to the first item in the list. The limit is a hard limit on how many items whether it's the raw list or that from an active search & is how the plug-in has done that since whenever it was I added it in the mid-2000s. It's also why trying to scroll / arrow down further won't work as it can't show more than has been set into it.

There is the option on the jtf plug-in's display tab that allows for disabling the sorting of the results so they're maintained in playlist item order which might help though I've not fundamentally changed how the jtf handling is done by the plug-in compared to how it ran under winamp 5.666 & the defaults are intended (sans bugs with the delay on loading being tied to the search slider) to allow things to just work in a sensible manner.

As part of getting the un-skinned window to not have all of the visual issues it's got (mostly related to dpi handling issues), the next build reduces the overhead when trying to paint the items in the list which reduces some of the issues for needing to have the limit option there but I've still to implement the proper solution (using a listview instead of a listbox) as that involves re-working most of the plug-in & I don't have the time for now.

The only show results if there's an actual search option is doing as it's intended in that it's the quickest way to get the jtf window to load & would've been a request from way back & is one I used to use a fair bit on my older P2 & Athlon setups that most of the early plug-in dev were done on.

3) I'm trying to coerce a plug-in to run in a situation it was never intended for whilst trying to not over complicate what I'm having to do for it whilst likely not getting things 100% right for what it's wanting / expecting which isn't going to help with cpu being different despite my attempts to get it lower & for which I know there's some aspects that could definitely be better but for now it's more about does it work generally well enough vs is that time trying to further optimise worth it against using it for other work so getting to make a gen_ff replacement can be started sooner.

How much more cpu for you setup are you finding it's using? Also the skins themselves have an impact on what is attempted so trying to have a 60fps render target yes isn't maybe the best but dropping things down then also makes the skins lag on their action animations & so on. I might add a 15fps mode.

Overall it's always going to be a compromise between letting it run in a manner that should then match up to the common screen refresh rates whilst yes potentially using some more cpu than would be liked even if it's deemed the very low / fractional of a percent. There is also the counter option in that using a classic skin might be more useful of cpu is a concern as that doesn't come with that baggage & I've been able to do a lot of optimisation on that count to be lower than 5.666.

-dro

[Altus]

1) When you say "metadata from the local library" do you mean the "Media library"? I have deactivated it completely and this could explain why it works differently for you, if the changes you made in the next build have nothing to do with it. With Winamp I can load the playlists however I want, they are always loaded correctly.

>> Update <<

Okay, I started all over again with a fresh WACUP full installation. And lo and behold, the playlists are also loading correctly. So I deactivated plug-in after plug-in to see which one was to blame, but it worked all the time. But then I realized the difference: Shuffle! Shuffle is practically always on for me, if I turn it off then I can load all playlists just like in Winamp.





Something seems to work differently with the shuffle in WACUP than in Winamp. Firstly, the loading of the playlist and secondly, WACUP (if you start WACUP with a *.m3u8 file and shuffle is on) always plays song #1, which I assume should not be the case.


2) I've been using Winamp "since forever" but I have no idea what's going on under the hood. And I've only known WACUP for a short time and therefore know much less about WACUP than about Winamp. I am only reporting as a beginner WACUP user what I have noticed. The way it is for me at the moment, setting a search limit is useless for me. Even if the idea is quite clever, I lose the ability to scroll quickly.

I already said in post #1 that it would probably be difficult to change the plug-in so that both are possible. The cursor would have to start on the current song and then distribute the limit up and down. Then even a limit of 100 would certainly be enough. But it's not so tragic. The songs are only on a SATA SSD but the search is still quite fast. But Slower than in Winamp, by the way.

But WACUP isn't finished yet, so I'll just wait for the final release!


3) About performance and timers: Here too, of course I had no idea that there were so many dependencies. My Winamp always runs in "Windowshade Mode" and all animations are always completely deactivated via the skin option, so I only see the effects of the timer in Winamp on the scrolling song ticker and the spectrum analyzer.

Regarding CPU utilization: This varies depending on the CPU, of course. I only have the values of a 24 thread CPU at hand. However, Winamp is also used on an old 4-core with 8 threads, where the difference is much more noticeable. Winamp and WACUP are compared with the original Modern Skin when playing the same song. The animations are deactivated on both and both run in Windowshade mode.

For a better understanding: 100% / 24 threads = 4.16% would be one thread.

@60fps/16.6ms:
Winamp: 0,19% (min) 0,25% (max) WITHOUT Scrolling Song Title.
WACUP: 0,24% (min) 0,29% (max) WITHOUT Scrolling Song Title.

Winamp: 0,21% (min) 0,31% (max) WITH Scrolling Song Title.
WACUP: 0,25% (min) 0,32% (max) WITH Scrolling Song Title.

@30fps/33.3ms:
Winamp: 0,17% (min) 0,22% (max) WITHOUT Scrolling Song Title.
WACUP: 0,22% (min) 0,29% (max) WITHOUT Scrolling Song Title. << Almost the same @60fps ??

Winamp: 0,17% (min) 0,24% (max) WITH Scrolling Song Title.
WACUP: 0,25% (min) 0,32% (max) WITH Scrolling Song Title.

Hidden (ALT+W):
Winamp: 0,09% (min) 0,12% (max)
WACUP: 0,18%  (min) 0,24% (max)

@15fps/66.6ms (my winamp default):
Winamp: 0,09%  (min) 0,12% (max) WITHOUT Scrolling Song.
Winamp: 0,14%  (min) 0,20% (max) WITH Scrolling Song.

Interesting that if you hide the main window and only show the tray icon (ALT+W), WACUP uses twice as much CPU as Winamp. The values seem ridiculous, of course, but this is due to the number of threads. Nevertheless, the utilization is significantly higher than with Winamp. But if the switch to 30fps in WACUP doesn't really help, then a switch to 15fps probably won't either. Apparently WACUP simply works differently than Winamp.


Oh, one more thing: When I unpacked the fresh installation and clicked on the "Disable Local Library plug-in..." the following dialog appeared:



I think there are a few typos in there

[dro]

meh, browser crashed on me whilst I was making a detailed reply on this so I'm going to give a quick reply so apologies if it's a bit curt.

1) I'm not seeing it still but I did find something else on an unrelated bug fix that could cause a cached title to be used at times along with a multi-threaded access issue with the shuffle list so I'm hoping fixing both of those aspects might help with this for the next build. If not then I'll have to keep trying at things.

Winamp & WACUP are different & it's more akin to Chrome vs Firefox in that the end result is the same or near enough but the way it's done to get to that differs.


2) How you're describing things, I've got to wonder if the jtf window that wacup offers is even what you've been using with winamp. As it was the default way for it from 5.04 to 5.666 unless the jtfe plug-in wasn't installed / enabled which'd then provide a simpler form that's just search box, list & close button instead of the one with the queue & manage aspects.

As everything else being raised shouldn't be new behaviour for a long time user & tbqh is leaving me somewhat more confused when the behaviour if not using the basic jtf version hasn't fundamentally changed between the jtfe plug-in when it was included with winamp & now in it's wacupified form.


3) Winamp Modern would be the most likely reason (along with my glue code to get the gen_ff plug-in to load not being the same as what winamp offered so might also be causing some issues) as not all revisions of the skin act the same & WACUP's copy is different in a number of ways to that from 5.666.

I'd completely forgotten about there being one change that I'd not gotten back around to looking at from reports a year or so ago & it relates to how the skin reacts to live bitrate changes being reported by the input plug-ins (aka how often the kbps part of the skin window updates based on a skin scripting notification it's reacting to.

That handling isn't directly linked to the skin timer aspect & with a change made to the wacup copy of that skin, it basically tries to update things as soon as it gets a notification & lots of little notifications vs how gen_ff works means higher cpu load. If I smooth out the rate of updates the WACUP core makes of the notification message that gen_ff reacts to in order to generate the skin script notification then the cpu load drops a fair bit for me & is around the same cpu level I'm seeing for the bento based skins.

Numbers wise it's typically sitting around the 0.5-1% level when playing with the odd peak to 2% or so when it was sitting around the 1-2% level with odd peaks to 4% before. Am on a 3700X so 6.25% is my peak for a core. There's some other changes applied on the glue code to get the plug-in to run under wacup which hopefully will get things down to a more reasonable level.

One thing you could try as you're comparing to 5.666 is copy the Winamp Modern skin from it into the WACUP skin's folder by giving the copy from 5.666 a different folder name so it's easier to compare against & see if that does match up to what I think is going on. The wacup core will still be useful for any of these skins as even if the skin doesn't immediately react to the information changes, the gen_ff plug-in is then having to do more work before the skins & their script timers trigger to do an information update check & trigger any of the needed ui element updates.


4) Typos on that & in a few other places should be fixed.

-dro

[dro]

The request for more / all of the generic embedded windows to be accessible via global hotkeys has now been internally implemented with any of those windows being automatically made into an available hotkey action to be able to toggle the window state.

-dro