Latest restricted WACUP beta release is build #18654 (March 24th 2024) (x86 & x64 changelogs) | Latest WACUP public preview is build #17040 (September 30th 2023) (x86 only)


NOTE: Beta testers are added in a limited & subjective manner as I can only support so many people as part of the beta test program to keep it useful for my needs.

Unless I think you're going to be helpful, not all requests will be accepted but might still be later on. Remember that beta testing is to help me & the limitations currently works for my needs for this project.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dro

Pages: [1] 2 3 ... 101
1
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.
Nothing has changed on Discord's side afaict but it seems that how some other solutions have attempted to do it is still working. As such a few weeks back I got around to implementing things in a manner that should work without having to rely on a 3rd party hosting site to work which'll be part of what becomes the next preview build in the not so distant future.

-dro

2
This'll be done as a right-click option on the history node's context menu. Was debating having it be auto-applied but that was going to complicate things a bit more than I necessarily like to implement for the moment. It means another manual step but just having something for now much like with the library playlist refreshing should be enough when I'd expect for most that they don't need to refresh it too often.

-dro

3
Preview Build Discussion / Re: Library Scanning
« on: March 19, 2024, 06:08:29 PM »
It's a known bug with WACUP's local library plug-in which your setup seems to be one of the ones more sensitive to it.

The prior build I assume you were using might've been the 1.0.21.7236 build & that was still re-using the plug-in from 5.666 whereas anything in the 1.9.x build range is using WACUP's own implementation which due to being new has some teething issues & I'm still working on testing the changes which should finally resolve it.

The scanning state is something my plug-in does to indicate something is meant to be happening but the nature of bug means it won't always break out of it & so it will just sit there basically doing nothing. The only solution is either going back to a prior build or waiting a few more weeks for me to get everything finished off & verified with a new beta build before the preview build will then get an update for this & a slew of other related issues that the current preview build is experiencing.

-dro

4
It's based around using 'album artist' for the matching with it then falling back to 'artist' if that doesn't exist (depending on the config options used). For vgm based sets as that looks like it might be, I know for some of them they often don't seem to want to group nicely as the album artist is somewhat treated as a per-track artist field.

The solution is to either try to re-tag them (which if it's vgm sets would mean that it's just custom metadata being stored in the local library db & not the actual files as writing tags for most of them often isn't supported) which'd then get things to group correctly but is relying on the db being maintained (which is probably why it's messed up if you had to start over). The other option would be to go to preferences -> media library -> local library -> uncheck the option to use 'album artist' & it'll then just look at 'artist' & that might be a better fit for the media you're using (is notes with that option about the recommended option above).

-dro

5
I get the potential for confusion but I also think that there's enough context between title as a metadata field & title as a formatted string for it to not be a problem & as such I'm not going to change the column name as that's then introducing more disparity into things vs existing usage of the term.

Will add the request to refresh the existing history titles to the todo list.

-dro

6
So what should the column name be? I am going to note that pretty much everything else I can see is using title for the pre-generated strings (main & library playlists, bookmarks, podcast downloads) & it's only the local library where there's a difference only due to how it's interaction with the lower level metadata.

-dro

7
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

8
That's good to know those changes did work as intended.

-dro

9
Preview Build Discussion / Re: *** in Songticker
« on: February 29, 2024, 06:18:51 PM »
They're not & it's either asterisks or what might have been manually set to be repeated or the skinned font equivalent depending on the font mode being used. Either way on preference there's changes now made which should allow the request to be met along with a $rating([filename][, star_mode]) ATF method addition which can output the imho nicer unicode stars or the asterisk with the star_mode parameter instead of the $repeat(*,%rating%) alternative.

-dro

10
Preview Build Discussion / Re: *** in Songticker
« on: February 29, 2024, 03:25:43 PM »
At least someone is paying attention. Adding it for classic skins is simple enough, for modern skins it's either requiring them to be modified on a per-skin basis or trying to hook / patch things generically to try to strip it out which isn't something I'm going to spend time on doing at this point & most afaict tend to do the left/right bouncing by default over the continuous scrolling mode (something I've still to get around to adding for classic skins).

-dro

11
Preview Build Discussion / Re: *** in Songticker
« on: February 27, 2024, 02:45:03 AM »
I've now had a proper look at this & the majority of the issues I was seeing mainly seem to relate to dev / beta build changes & doesn't seem to massively affect the current preview build.

As for the ' *** ' handling, that's now been changed so the option on the prefs page noted above can be toggled on/off whether the default text or a custom atf string is being used which afaict should allow you to achieve what you're wanting if the existing suggestions don't quite work.

-dro

12
Preview Build Discussion / Re: *** in Songticker
« on: February 25, 2024, 01:29:01 PM »
The only way currently is by going to Preferences -> General -> Taskbar -> Taskbar Text -> un-check the 'Scroll the text in the taskbar' option or you could try using the custom text option & un-checking the 'Append ' *** ' at the end of the title when title scrolling is enabled' option with that.

Though I've got to double-check the options on that prefs page as some aspects don't seem to be working as I'd expect in the current beta / dev build along with making sure that if ratings are set to be shown that they use the nice looking stars instead of the *** which is there by default for compatibility with external programs that might try to scrape the currently playing information from the program title text.

-dro

13
It's also possible via the 'q' action to control what's going to play next. By right-clicking on the stop button -> on end of queue -> uncheck 'use setting only this time' & then going back & selecting the 'stop playing' option on there, when a file is selected as the next play by selecting it in the main playlist & pressing 'q', once that's been played it'll then stop on there (or go to the next playlist item depending on the other playback options).

If it's something that's always wanted on specific items then the separator option might be the better way to do it as there isn't any virtual metadata to link such a behaviour to items as things currently stand with wacup.

-dro

14
Skins / Re: New modern skin : Cell RC1.
« on: February 11, 2024, 09:28:26 PM »
Post edits are limited to a few hours. Neither of the urls you've posted are valid so I can't fix the first one for you.

-dro

15
Preview Build Discussion / Re: WACUP - First experiences, bugs, wish list
« on: February 01, 2024, 04:15:45 PM »
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

Pages: [1] 2 3 ... 101