Latest restricted WACUP beta release is build #18980 (April 24th 2024) (x86 & x64 changelogs) | Latest WACUP public preview is build #18980 (April 24th 2024) (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 ... 102
1
The older preview builds are still referenced on the site by following the prior / last preview build link from near the top of the initial text on the site's main preview build page.

I've tried to play all of the links in the example playlist & as-is none of them are working for me either in the current preview or the very old one (which ended up hanging whilst trying to do anything but that might be to do with whatever I'd last done to that test install a few years ago) nor in other players / browsers.

However the problem seems to be because the old preview build would try to force streams to use http:// when https:// was found as that's what was needed to allow the re-used in_mp3 plug-in dll from 5.666 to be more likely to play things.

The newer build has long since resolved that problem & that re-used in_mp3 is now able to try to play the stream urls as-is which is a problem here because what you've provided doesn't respond on the https:// urls from the server side (ideally there should be an attempt to drop back to http but the connection is also taking an age to timeout it seems).

If you edit the stream urls to use http:// then just the sc1 & sc2 server urls don't seem to be responding from my testing.

-dro

2
It's likely how I'm mapping the skin file / folder to a menu item index & based on the video it seems to be counting the empty folder which depending on how the drive returns the order of files (normally alphabetically with ntfs) would then place an a / b named folder before the bento skin items which if it's what I'm thinking would cause it to act as is shown (i.e. it's selecting the 'hidden' empty skin & reverts to the default skin instead of skipping that folder & using what was set for the menu string).

-dro

3
When the beta & the preview are the same build then it's fine.

As for the prefs issue, I had a todo note in the code since it wasn't something I'd yet implemented when dropping legacy mode & should've had the button be disabled. As that prefs page used to heavily manipulate what the winamp core was providing & when all of that got dropped I'd just not gotten around to implementing it since I'd not had to when the winamp core was able to handle the action for me. Is now sorted for the next build.

-dro

4
I can confirm that clicking the "Set skins directory..." button does nothing.
Have added it to the todo list though I've not checked why it's not reacting like it should.

As for darkhell's reply, I'd need confirmation whether it's happening with 18980 or not as I can't get that failure to occur & only can with the older 18916 build which was the one out when this thread was started.

-dro

5
I've quickly tried with that copy along with the selection of different ones I seem to have collected (most of them seem to be the MMD3-4-5 variant of the skin) & it all seems to be behaving correctly. Are you using Win11 by any chance?

In all honesty I'm not sure why the menus / text are getting screwed up for you as it's acting like it's not seeing there's any text to draw which shouldn't be happening. As I'm writing this, it's reminding me of some weird things I've seen reported with gaming anti-cheat software or when I had the skinned menus enabled for WINE setups (which is hard-coded to not be enabled under that use case for now).

Something to try is going to Preferences -> General -> Appearance -> un-check the use skinned menus option & see if that makes a difference (am not expecting it since the listview contents are also screwed up). If it does, then try re-enabling & using the custom menu font option to see if that still misbehaves or not.

To cover something else mentioned, WACUP doesn't setup any file associations in it's preview state (is noted during the install process) which is why WAL needed to be manually associated.

-dro

6
Preview Build Discussion / Re: No Font with MMD3 skin in latest build
« on: April 30, 2024, 07:42:46 PM »
Can you provide a copy of the MMD3 skin that you're using please. As there's so many different copies of that skin out there it could be something specific to one revision especially as MMD3 is one of the ones I often use to double-check that gen_ff under wacup is behaving.

-dro

7
It already has native scrobbling support (preferences -> playback -> last.fm scrobbler) with it also able to update the now playing part on the last.fm site though I never looked at the love support so am not sure if that'd fit in with how I'm doing things or not or whether it's something their api provides access to doing.

-dro

8
Skins / Re: Convert / Update old skin?
« on: April 24, 2024, 12:04:28 AM »
The skin is working correctly for one from 1999 which pre-dates the classic skin additions that Winamp 2.9x introduced in 2003.

If you get a copy of the Skinner's Atlas then the gen.bmp & genex.bmp from it are the files that would need to be added into the old skin along with reading the txt file in the wsz (it's just a zip file so there's nothing special about it) or there's an online copy at https://github.com/WACUP/Winamp-Skinning-Archive/tree/master/Classic%20Skins/Skinners%20Atlas to read through.

There should be enough from the old skin to be able cobble something together to create those 2 files & then you can add them into the existing zip file or leave it as a pre-extracted folder within the Skins folder.

-dro

9
There'll be a fixed build in the day or so. The problem has existed for a couple of years in my code & despite it not having been changed for the new build (haven't gone back & checked other recent beta builds) it seems to be manifesting in a more consistent manner if going to the base skin is involved as part of the chain of switching attempts.

-dro

10
Have now replicated the issue & am looking into what might be going on.

-dro

11
I've had another user report this earlier today despite it not having been mentioned with any of the betas from the prior few month's so I'm not sure why it'd now be messing up other than it's somewhat the nature of trying to re-use the modern skin plug-in gen_ff dll from 5.666 & something yet unknown to me isn't working right.

Compared to the old preview they are for the most part 2 different implementations now & gen_ff was never really meat to be able to work outside of a native winamp implementation as WACUP is now doing.

All I can suggest for now is to try running wacup using wacup.exe /procdump to see if there might be a weird crash happening (something that gen_ff can randomly do) & it could be that's happening & measures to try to avoid a full crash are actually working at the expense of a weird non-skin changing experience.

-dro

12
Skins / Re: Big Bento Modern v1.2
« on: April 18, 2024, 09:02:14 PM »
Could you share fileinfo.m and sc_aerosnap.m for Big Bento Modern v1.2.3, please?
The 4 modified .m files have now been attached as a zip on the first post.

-dro

13
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

14
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

15
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

Pages: [1] 2 3 ... 102