Latest restricted WACUP beta release is build #18798 (April 7th 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
Skins / Re: Big Bento Modern v1.2
« on: April 15, 2024, 11:20:40 AM »
Or maybe I'd not seen the question & as modifying the skin is something anyone can technically do unless what you've still to ask is a gen_ff / core implementation aspect & then who knows what can or cannot be done, rather than asking if it's ok to ask, just ask for it.

-dro

2
Preview Build Discussion / Re: Playback Question
« on: April 09, 2024, 11:54:18 AM »
That action hasn't had any control over the behaviour used nor has WACUP's handling of it changed in a long time so here's what is coded.

If you use the action from the right-click menu or the open action in the main window then it treats it as a play action which'll clear the existing playlist & start playing be it the first item or the first one in the generated shuffle table. That's also why those actions are named / placed where they are.

If you use the add folder option from the playlist editor then that will treat it as an enqueue event & won't change what's playing.

Maybe that menu block could be changed to follow the media library default action (play/enqueue/enqueue & play) with it updating the text for the root of the menu item to then have it contextually be correct.

-dro

3
Using files correctly tagged with albumartist is the preferred option. Alternatively going to preferences -> media library -> local library -> unchecking "Use Album Artist when grouping the Album & Albumart filter results" might in some cases group things in a more expected manner depending on what metadata has been found from the files to start with.

-dro

4
General Discussion / Re: Windows 11 screen doesn't turn off.
« on: April 03, 2024, 10:44:55 AM »
Using either of the DSP plug-ins shouldn't make a difference to the behaviour about staying awake or not as it's the playback state which determines things & not the DSP which is just part of the input -> output chain going on.

-dro

5
Preferences -> Advanced -> Error Reporting -> uncheck "Send crash report via email using default email program (if available)" then that'll avoid it using what's basically a fallback mode as WACUP will also auto-submit the crash report (as long as it can be generated) to the server. The error shown appears to be from the OS itself & there's at least 2 different ways the OS recognises what's the default email client & iirc the api that I use doesn't seem to see it for some which is why it's simpler to un-check the option noted).

re: your crash, if you go to preferences -> plug-ins -> output -> in the drop down change from Not So Direct to Not So Yasapi & that should avoid the issue the Not So Direct plug-in is having with some setups like yours due to how it's trying to manage the output device.

-dro

6
General Discussion / Re: Windows 11 screen doesn't turn off.
« on: April 02, 2024, 10:20:27 AM »
Preferences -> Playback -> Playback tab -> uncheck "Use system keep-alive (default: on)"

That's enabled by default as there's numerous setups where the device / monitor needs to be kept on for the audio to be heard (e.g. due to integrated speakers) but in your instance it's not going to be helpful hence the option.

-dro

7
General Discussion / Re: ReplayGain calculation is broken
« on: March 28, 2024, 03:05:41 PM »
The "missing required decoder" could be related to a known bug with the newer preview build. There's a fix is already in place with the 18654 beta build ("Fixed a recurring failure when trying to send files to be processed for replaygain due to a timing & feature validation conflict when checking writing replaygain metadata is supported" unless it's actually a real case of being a file type not handled. At least the newer preview build is seemingly working better than the one you had been using when it comes to the RG handling.

-dro

8
General Discussion / Re: ReplayGain calculation is broken
« on: March 28, 2024, 02:38:40 PM »
https://getwacup.com/preview/ has the current public preview builds available (all of the builds that have been provided are essentially betas whether they're limited access or done as public previews).

If you're concerned about breaking an existing install then you can easily make portable test installs with the WACUP installer to check if the newer build resolves the issue or not. If it doesn't help then I'll need more information on the files being sent &/or some example files.

-dro

9
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

10
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

11
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

12
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

13
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

14
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

15
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

Pages: [1] 2 3 ... 101