Messages

31

General Discussion / Re: Procrustes question

« on: January 29, 2024, 01:43:59 PM »

Skins + old plug-ins are a pain in the whatnot at times. Glad to hear it got you to be able to see the plug-in ui.

-dro

32

Preview Build Discussion / Re: WACUP - First experiences, bugs, wish list

« on: January 28, 2024, 02:43:45 PM »

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

33

General Discussion / Re: Procrustes question

« on: January 28, 2024, 01:47:15 PM »

I recognise the plug-in name but don't remember too much about it nor what it's ui was like. It could be it's either not creating it's window but not indicating the failure or is doing it in a manner that's placing it off-screen (it's an old plug-in from what I remember so may not be behaving on more recent versions of Windows).

The other thing is if it's providing it's own custom ui, it might not be behaving well if using a modern / winamp3 style skin of skin (e.g. anything bento based, winamp modern, cpro, mmd3, etc) & using a classic / 2.x style of skin might allow it to find things (probably best to change to the skin & then restart wacup after doing that as those plug-ins which didn't behave with such windows would often not detect skin changes properly either).

-dro

34

Skins / Re: wasabi.list.text.selected.background.inactive

« on: January 25, 2024, 12:28:55 PM »

How about we wait to have a fixed WACUP beta build to use when the scope of access to that build & it's issues is minimal vs going at things that yes should probably be defined in the skins (easier said than done for much older skins) but were seemingly fine previously under earlier beta builds. I don't however disagree that in an ideal situation all of those skins would be fixed up to provide everything that's needed but the nature of modern skins & different gen_ff/wasabi targets makes them a mess to handle with & is no wonder at times that things might fail even when accounting for running them under a plain winamp install let alone with what wacup is trying to achieve with that plug-in & re-using it.

The gen_ff plug-in was never meant to run in something outside of winamp so what is having to be done to try to achieve that is changing things that the plug-in wasn't expecting & if as it seems to be strongly related to how a libpng implementation that's different from what gen_ff was built to use (1.6.x vs 1.5.x) is dealing with older png files (which covers so many of the modern skins due to it being an effectively dead art) is likely the problem & is able to be changed to work in a more compatible manner then things missing in xml files which shouldn't have an impact could be completely unrelated & just happens to be a more obvious potential trigger point when other skins with that aspect are also able to crash in that & older wacup beta builds.

-dro

35

Preview Build Discussion / Re: SMTC not using album artist

« on: January 23, 2024, 12:57:27 AM »

It might be better to ask them assuming they're active vs me trying to have a go eventually at some point plus python isn't something I can try to get into at this time with everything else I need to get done.

-dro

36

Preview Build Discussion / Re: WACUP - First experiences, bugs, wish list

« on: January 23, 2024, 12:49:46 AM »

>> 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

37

Preview Build Discussion / Re: SMTC not using album artist

« on: January 19, 2024, 05:29:38 PM »

As long as the files playing have the metadata then it doesn't really matter. The local library acts like a cache so it makes getting the metadata faster but for wacup I've also tried to do things unlike with winamp so it'll do caching of the metadata requests for direct reads to avoid performance hits against that.

The main reason for asking where the files might be handled is because the metadata cached in the local library db is what will be used over the file's & changing read settings may not always cause that metadata cache to be refreshed without manual intervention (something that the beta does a bit better than the current preview build you're using).

From what you're trying to use, as long as the scripts are querying the right things then I don't think there's anything I can really do as my code is setting all of the values it can & then I don't have anything else to do with it until the next song related update that's needed.

For the other plug-in, what you posted is probably what's needed to get it to send the information but you then need to get it to build with those changes. Also from a quick look at the python script, like you say it doesn't even look for albumartist (just artist, title & playback position if I'm reading it correctly) & if I had any inkling of python scripting I'd try to check what values are being held in the current_media_info[] object to inspect what it is holding from the smtc api.

-dro

38

Preview Build Discussion / Re: SMTC not using album artist

« on: January 19, 2024, 03:31:08 PM »

The playlists aren't the same as the local library. The local library is the part within the media library window & the local library node / sub-nodes shown within that & it's within the options for it where metadata refreshing can be triggered assuming you've either added files into it or have it set to add what's been played automatically (default behaviour).

If you're getting the expected %albumartist% back for playing metadata then wacup's plug-in (which is cppwinrt based & not c# based like the one you've mentioned) should also be getting that too as it's handled via the same internal api calls to get file related metadata. So if the title reading is working, the plug-in should work & right now I don't see why it'd not be working (I've yet to check back over the past 3 months of dev work to make sure it's not down to something else being wrong) since as long as I get an albumartist string back I set it on the MusicDisplayProperties object.

How are you checking that it's showing the wrong albumartist? As I don't see it exposed in the Win10 ui.

-dro

39

Preview Build Discussion / Re: SMTC not using album artist

« on: January 19, 2024, 12:02:16 PM »

Are the files being played in the local library ? If so then that will usually return artist for albumartist if it's not specifically set in the file metadata & for some of the cases with it not being in the local library db, the handling might emulate that behaviour when the files are directly queried.

As WACUP's local library plug-in follows that behaviour for compatibility vs expectations with Winamp's local library plug-in though it can be disabled (preferences -> media library -> local library -> uncheck 'Use Artist for Album Artist if not available when reading metadata' but it'll then require a refresh of all of the local library metadata & might cause other things to not work in an expected manner for filter / album related groupings.

Before even doing that, just double-checking what metadata might be in the local library db for the albumartist value &/or the file directly would be the best starting point to make sure it's not actually working as intended vs the data that's available to the plug-in requests.

WACUP's SMTC handling is using the albumartist field that the local library (or the direct file handling if not in the local library db) record returns & doesn't have any context to work with to adjust things (per my blurb above). From a quick look at that repository it seems to have no context of albumartist & just sets song.artist for both artist & albumartist fields.

-dro

40

Preview Build Discussion / Re: Ogg Vorbis Freezing + Fix (Windows 10 / 11)

« on: January 17, 2024, 03:43:00 PM »

This is likely exacerbating a couple of bugs within the WACUP builds from the past 6 months or so where the Ogg based formats aren't correctly setting up the file access on accessing them & also aren't correctly releasing the handles to them which along with what that OS extension (though happens without it present) seems to be a worst case scenario. There are fixes for the bugs I could replicate within my own handling, no idea how it might work with that OS extension as I've not installed it.

-dro

41

Skins / Re: Defix Neom (skin)

« on: January 04, 2024, 10:42:51 PM »

That's a gen_ff handling issue which can affect any skin.

-dro

42

Wishlist / Feature Requests / Re: Dynamic Album Art for Discord's Now Playing

« on: December 21, 2023, 12:59:48 PM »

The Discord<>Spotify integration is specifically implemented on their side as I understand things & isn't a nice way for others to make use of it (e.g. not being able to set "listening to" instead of the hard-coded "playing to" for the overall status).

For other app integrations, there's not a formally defined way to do it when I last looked into it a year ago but there seemed to be some hacks that could possibly achieve it but it requires uploading things from the WACUP client to a server to then host those images & fiddle what WACUP sends on the client update.

Without looking into things again I don't know if anything has actively changed on the Discord api side of things to formalise what can be done or if it's how it was when I last looked.

-dro

43

General Discussion / Re: Drag and drop a music folder with a playlist file adds duplicate files

« on: November 24, 2023, 11:01:16 AM »

I get what you're describing, I just don't remember it as being a thing Winamp would do from having previously worked on it to ignore playlists found within drag+drop actions though I see 5.666 acting as described from a quick re-test so I guess my memory of things isn't all that great nowadays. Maybe I need to consider adding in an option to ignore playlist files on drag+drop actions.

De-duplicating what WACUP adds from drag+drop actions along with trying to use the playlist ordering &/or metadata to get the expected track order to deal with Explorer not often providing files in the expected order (due to file creation, selection quirks in Explorer) is something already on my list of things to do. So doing all of that might be the more sensible thing to do with my time vs an option that imho could cause more issues than it helps, will have to have a think & see when I can schedule it into things.

-dro

44

General Discussion / Re: Drag and drop a music folder with a playlist file adds duplicate files

« on: November 24, 2023, 01:31:35 AM »

No such option currently exists & a smarter handling of drag+drop still needs to be coded so for now it'll just add what it's given even if that then duplicates things. I'm also not aware of Winamp having done any filtering of things either since both programs just parse the given list of files from the drag+drop action.

-dro

45

Preview Build Discussion / Re: Media Library refresh should be more clever

« on: November 20, 2023, 03:22:20 PM »

Without trying it out I'm not sure but it's something I've got on my of things to consider once I can be certain of the core input plug-ins being able to cope with it. The folder monitor handling is itself multi-threaded so it checks for files to consider & then hands that over to a different thread which then does the metadata reading allowing for the initial scan to generally take less time. That's still hitting multiple files on the drive at the same time due to the overlapping of things relying somewhat on the OS / file system cache to minimise the effect of it.

-dro