Latest WACUP public preview for x86 & x64 is build #20202 (September 28th 2024) (x86 & x64 changelogs)
Latest restricted WACUP beta release is build #20202 (September 28th 2024) (x86 & x64 changelogs)


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 ... 111
1
However I'm still seeing it intermittently prevent WACUP from closing normally when the plug-in is running so I've got to look into that.
I've possibly found something that'll better allow the process to close irrespective of plug-in / external dll weirdness messing up things from what I could see with this plug-in so hopefully the next build will be better behaved on all counts.

2
I'd not seen the edits & luckily hadn't purged the legacy crash reports from the older builds that I do periodically though the crash didn't seem to show me much other than morphyre was trying to call something no longer there when process close was happening.

With the crash on loading, I made a change for the x64 build just before 19516 was created with how the embedded window frames are able to be created by plug-in as Morphyre uses & it messed up an expectation of how that works for the x86 plug-ins. I've now changed that back & its loading ok again. I've also fixed it to use the correctly scaled window frame so it'll match the look of the classic skin scaling.

However I'm still seeing it intermittently prevent WACUP from closing normally when the plug-in is running so I've got to look into that.

3
That's good to know & saves me testing things tomorrow if it's working ok for you with the in_mp3 suggestion.

When in_mp3 is finally dropped I should have gotten my handling to be equivalent for local AAC & you shouldn't notice a difference 🤞 Though I still think it's better if possible to get them into a container format like MP4.

4
The changelog pages don't link to the builds as those are mostly the beta to beta build changelogs & I don't openly provide them (even though the preview builds are just public beta builds).

The preview download page has links back to prior preview builds & those for now still have old build links.

Also you've referenced the x64 preview build & that can't do my in_mp3 suggestion as it's pure wacup & cannot load any winamp plug-ins since it can't use x86 / 32-bit dlls.

5
As part of me moving WACUP away from re-using the handful of the remaining plug-ins from 5.666 to do playback, etc there's been an overall swapping over to WACUP native versions & raw AAC playback was one of those which happened earlier this year.

Seeking in raw AAC is something I've still to implement (which'll have to be a crude brute forcing since such files aren't really designed for nice seeking like AAC in an MP4 container) though pausing should be working. You could try setting AAC back into the in_mp3 config but I can't guarantee that'll work due to other things in my core that control which input plug-in is going to be used for various file formats.

6
Simple option is change the active output plug-in to wasapi & see if that makes a difference. As either the output is clipping silence or the MP3 decoder is doing it but that's a bit more involved to change around (unless you make a test portable install using the x64 build so the existing installation isn't altered & the x64 build uses a different decoder plug-in compared to the x86 build which would rule out decoder vs the files being played).

7
Do you remember what file type(s) those affected files might be?

8
Whitespace is stripped before the multi part query is run which is part of the reason for the behaviour.

Quoting "abba" (with or without the space) iirc should do it otherwise I can't remember if there's a fuzzy vs exact search matching option on the local library prefs page. If not it's getting into using the question mark prefixed manual query support to get the results wanted.

9
I'll have a look once I resume development later this month. I can't think of anything obvious as to why it'd be misbehaving if it had been ok with the almost 4 year old build as not much has been done when it comes to vis handling. As for multi-vis some plug-ins just won't behave as they were never meant for such things especially if trying to run under a modern style skin.

10
The 2 should be able to run dual installed without issue if they were installed into separate folders unless you've managed to put them both into the same program folder.

The simplest thing to try would be to remove the wacup program folders (e.g. c:\program files\wacup & c:\program files (x86)\wacup) & then re-run the x86 installer.

Also what specifically is wrong with the autoplay especially if it's against any specific format(s)? As I'm not aware of / currently remembering anything obvious that'd prevent it from working as long as its been enabled.

11
Preview Build Discussion / Re: x64 directshow/nsv video decoder
« on: November 21, 2024, 11:53:07 AM »
I currently don't plan on adding nsv to the x64 build as I don't remember some aspects of it being available in an appropriate open license nor if it was even openly documented as a format or if there were some of the precompiled codec libraries that I think were needed being available.

As such nsv with my current thoughts on it would be left as optional for x86 only if the old plug-in & supporting dlls from 5.666 could still be obtained. It might be best to look at converting them into a more general format.



With directshow / media foundation support it's something I'm still weighing up how / what I'm going to do. As I prefer where possible to have things contained within the install folder instead of relying solely on external aspects to do the processing which can introduce issues outside of my control which is a pain to resolve.

So something will happen but for now the x86 build is recommended as it's going to be more feature complete compared to the x86 build since that wacup build can make use of well behaved winamp plug-ins whereas the x64 build is intentionally locked down to just being the pure wacup experience for the time being.

-dro

12
Can you not restore the removed file then start it normally & turn repeat off? Also is it repeat all or repeat track that you've enabled as well as what skin are you using? If you're not able to restore the file you could try opening the winamp.ini in the wacup settings folder & remove the repeat= line & then try again (though I can't remember if that'll help if a modern style skin is being used).

Not that it should be able to crash in such a scenario but based on the wording of things I've got to assume it's not triggering my crash reporter (if possible running wacup.exe /procdump once before trying to edit the winamp.ini file would be helpful to try to get a crash report so I can try to resolve whatever is going wrong here).

-dro

13
General Discussion / Re: Google instead of Bing for Artowrk search
« on: October 23, 2024, 08:12:41 PM »
Also, I'm still hoping to see the display of the Track/Total track somewhere...
You'll need to edit the skin to do that which will likely require editing & compile maki script files to achieve it - is probably better for you to do it (per this for some of the ways to go about doing it) or find someone willing to do it for you as you'll know where in the ui you're wanting it to appear, etc.

-dro

14
Skins / Re: Any way to make minor changes to an existing skin?
« on: October 23, 2024, 08:08:51 PM »
For the pink section, go to preferences -> plug-ins -> media library -> un-check the plug-ins you don't need & that'll remove those items after a wacup restart. Everything else would involve editing the skin as already mentioned (the red block might be able to be done via xml edits only otherwise you're going to be looking at maki editing to achieve things).

-dro

15
General Discussion / Re: Playlist Window resizing with monitor off/on
« on: October 23, 2024, 12:08:49 PM »
The main window can't change its dimensions whereas the main playlist window can & there's probably something going on that I've yet to replicate where maybe if the monitor is being turned off its causing a possible resolution / dpi change to occur that's then messing with things as a first guess though doing similar things from a quick test doesn't seem to do it so maybe there's something else running doing it.

What version of Windows are you using? Also just to rule out something, what happens if you have wacup set to run at 1x mode instead of double-sized.

-dro

Pages: [1] 2 3 ... 111