Messages

16

General Discussion / Re: ReplayGain calculation is broken

« on: March 28, 2024, 02:16:30 PM »

Not everything supports RG & the plug-in handling things will only accept files where there's an appropriate input plug-in that supports the format converter api which is needed to get the audio data without hacks to fake play things.

Without knowing what you're trying to process & also what WACUP build (as you've mentioned "both of options" which to me sounds like the old 2021 preview build instead of the 2023 one) it's hard to be certain if it's just a build bug or something else that I'm not aware off.

-dro

17

General Discussion / Re: ReplayGain calculation is broken

« on: March 28, 2024, 01:50:25 PM »

When you send files to have RG calculated via the send-to menu then a skinned window will appear to show what's going on.

-dro

18

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

« on: March 20, 2024, 02:49:37 PM »

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

19

Wishlist / Feature Requests / Re: ML History View Column Heading Change

« on: March 20, 2024, 02:47:20 PM »

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

20

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

21

General Discussion / Re: WACUP does not merge albums, instead creates duplicates

« on: March 18, 2024, 10:50:46 PM »

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

22

Wishlist / Feature Requests / Re: ML History View Column Heading Change

« on: March 07, 2024, 05:46:09 PM »

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

23

Wishlist / Feature Requests / Re: ML History View Column Heading Change

« on: March 07, 2024, 04:15:12 PM »

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

24

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

« on: March 07, 2024, 01:58:43 PM »

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

25

Implemented Requests / Re: Transport slider "Click" does not nudge/scrub (Regression vs. WinAmp)

« on: March 06, 2024, 10:20:10 PM »

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

-dro

26

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

27

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

28

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

29

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

30

Wishlist / Feature Requests / Re: "Stop after track" option in playlist editor

« on: February 14, 2024, 01:05:30 PM »

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