Latest WACUP beta release is build #9166 (October 21st 2021) | Latest WACUP public preview is build #7236 (March 11th 2021)


NOTE: New beta testers are not currently being added as I need to re-work the beta test program

If you've not already requested to be a beta tester & would like to then please send a PM to 'dro' to be added to the beta test group.

Note: requests to be a beta tester are processed in batches when new beta builds are released so please by patient of this process.

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 ... 82
1
Ok, will keep it in mind though as most of the plug-ins that'd be involved in getting to that state are not going to be the Winamp provided versions when I finally have a stable build to act as a new preview build, it's probably not going to be something that'll happen again (or it'll be all different issues since it'll be my code that's then responsible).

-dro

2
Preview Build Discussion / Re: Won't play CD Audio?
« on: September 30, 2021, 12:31:44 PM »
The issues mostly related to the drive(s) taking longer than would be liked to respond which can then trigger the unresponsive handling along with just making the process seem like it's not loading or just taking forever to load. Since I've changed a load of other things around it's possible I've already done some things that lessen that load time impact.

It's something I'm also trying to improve since I've gotten to having an initial build of WACUP not needing winamp.original to load (not something you'll be using as you'll need the existing mode to have gen_ff loading support) is further reducing the load time impact of as many aspects I can for which I'll have to do some testing again to see what the cd plug-in impact is with & without populated drives (real & virtual) & might mean I re-enable the plug-in by default on new installs when it has been selected to be installed.

-dro

3
Preview Build Discussion / Re: Big Clock Issue
« on: September 29, 2021, 10:36:11 PM »
Not as long off as I probably needed but I managed a decent week away last week for the weather for what me & my other half were doing (it's been wet & meh weather wise this week which wouldn't have made going up & down steep hills all that enjoyable) along with getting some needed IRL issues resolved.

-dro

4
Preview Build Discussion / Re: Waveform Seeker Display ...
« on: September 29, 2021, 10:34:06 PM »
Pre-processing the CD beforehand for playback is maybe a bit excessive since at that point it'd be simpler to just rip the cd (something else that needs to be sorted out).

The options that come to mind are either render things in realtime with the waveform seeker window being able to wait as new data is read in via playback. The other option would be to just buffer the whole track (which is the memory issue I'd mentioned) & then playback / render requests pull from the buffer - this would have the ability to allow the drive to spin down which might be useful in some instances but it then needs handling to allow the next track (more so if playing things in order) to be spun back up ready in time so it doesn't then mess-up.

Either way it's a non-issue for the time being but there's scope to do something towards it.

... not to mention that I now prefer it this way (and would likely take issue if it changed!) -  8)
Nothing an option wouldn't be able to resolve :)

-dro

5
Preview Build Discussion / Re: Waveform Seeker Display ...
« on: September 29, 2021, 06:31:04 PM »
It's an annoying inconsistency which would be nice to resolve for more of the cases where it happens & there's scope to get the data. As for streamed formats, that's a different kettle of fish as there's some where it is possible to display it if the render request was allowed to wait a while & then a cached / temp copy of the file (for radio streams it doesn't make sense as there's no end time unless it just offered a rolling output which is something that could be considered) & render from that. Like you say it's not a showstopper so it'll likely stay like it is for the time being :)

-dro

6
General Discussion / Re: Winamp as an open source project + Winamp vs WACUP
« on: September 29, 2021, 03:04:42 PM »
Quote
I'm just curious about the open vs closed source nature of this project. You haven't been able to re-write it except for parts and plugins to keep it relevant, So it sounds (and feels) like it's patchwork done pretty well.
Patchwork is a decent way of describing large aspects of things though it's not helped with how things have naturally developed over time. WACUP started out as a plug-in pack of some of my key existing plug-ins before evolving into providing replacement dlls / plug-ins for some of the Winamp 5.666 ones.

As part of that second stage I'd also started to make a loader program that'd allow me to inject what's become the WACUP core dll into the original Winamp 5.666 main program (which shows as winamp.original once WACUP is running) to be able to do live patching of some of the code within Winamp's program file which was initially to help change some behaviour that couldn't be done via existing subclassing & apihijacking methods (overriding some of the OS api calls) which were things I'd been using since 2003 when I got into making plug-ins.

I've also done binary patching of the original program file (e.g. disabling some of the anonymous stats collection) for things that it's just simpler to always prevent that code from the original program file to run.

The live patching / subclassing / apihijacking is what's then allowed for much more of what has become the patchwork replacement of things with the core along with replacement of more of the supporting dlls / plug-ins from 5.666 for WACUP provided ones. It was once I'd started doing much more of that at which point I changed the 'P' from pack to project & WACUP moved towards the end goal of being Winamp compatible with using Winamp to run.

In hindsight, if I was going to start out with making WACUP as it's own thing then I wouldn't have done things as I have since I'm now having to spend a lot of time essentially re-doing what I'd done so it doesn't then involve live patching but the piecemeal replacement of things has however had the benefit of better ensuring that plug-in compatibility is far more complete compared to what other players offer (they only offer a limited plug-in api & typically cannot support behaving general purpose plug-ins).

Quote
I'm just curious about your statement, "source code without a developer is completely useless", etc. I agree with that, but can I ask why open-sourcing WACUP leave it without a developer? I don't imagine the source code is "pretty" in this specific case, but would you feel a decline in ownership to accomplish tasks that need to be done?
I don't think I've said open sourcing WACUP (which I'm not ideologically aligned with doing) would mean there's no developer, it'd just more likely mean I'm no longer around / involved. I just don't have much faith in the many eyeballs thing that's always thrown about with OSS & how it's going to make software massively better since there's nothing to stop someone offering to make for example some of the input plug-ins that still need to be replaced but there's either not the interest either because of my stance on things or that it doesn't appeal to those that might be able to do it.

Another thing is I just don't want to do project management which especially accepting things on the WACUP core would bring & it's hard enough managing myself let alone others. The other thing is that the scope of what WACUP is doing probably could do with more people working on it for some aspect but there's no way I'd be able to financially compensate them since what I manage to bring in is massively below minimum wage & is just lucky I live a frugal lifestyle to stretch it out nor can I expect them to follow the unhealthy amount of time I do put into this (not helped that I personally think I'm a slow coder).

Quote
WACUP is a different case than other music players, but would that stop you from continuing to work on it?
In comparison to other media players which don't seem to have this same level of demand to be OSS, they're typically a few people at most with more often just being 1 core dev doing the majority of the work.

In some respects keeping it to how I'm doing it at that moment also makes it simpler to keep to the vision that's wanted as even from my days when I was working on Winamp proper I didn't agree with the way that it was trying to be taken for which I'm instead with WACUP trying to go in the direction of what I think Winamp should have gone i.e. embrace it for what it is instead of trying to change it more into an iTunes analogy whilst taking the time to look at how people are using it & make sometimes breaking changes where it's going to be more beneficial (this is something that the skinned ui massively hinders at times).

Maybe if I was more aligned with everything is OSS & that's the way to do it then I might've gone that route but there's also a bit of pettiness on my part in not wanting some of my plug-ins to be OSS as it would've allowed Winamp's current owners to then grab them for which I don't want to happen (e.g. JTFE). I do get that it seems conflicting as I'd also not go down the GPL route (which I know would resolve that assuming license compliance) as I don't like the nature of GPL whereas a zlib/bsd-like licensing being more how I prefer to do things which I know is at odds with my prior comment.

Not that it probably matters as they've made it obvious they don't care nor want to invest in the original program whereas I think there's still the scope of that vs going the everything is just a web app wrapped in electron as I'm seemingly a tech dinosaur but it's what I know & generally provides the end result that I want.

Quote
Is it mostly just plugins and DLLs? It seems like a potential monster to me. But again, no experience.
A large part of what is Winamp is plug-ins & dlls but there's also the loader program (aka winamp.exe) that manages & brings it all together. Its the replacement of that (the loader) which is where the patchwork nature of things is the most obvious & has caused some WACUP builds to be painful to use but it's ultimately time & perseverance & past experience since I spent over 7years just working against pre-compiled files before eventually working on Winamp so doing WACUP has been a bit like going back to those before times.

I do appreciate it's hard for me to fully convey what I'm doing at times but something that was always part of what I tried to do with my plug-ins was to make them seem like they were native & doing WACUP is ultimately taking what I did for them & stepping things up a few levels. So as long as what is provided works then it probably doesn't matter too much how I've done things (as I doubt most care about patching techniques & the problems between cdecl, stdcall & fastcall conventions) & just that it works preferably without any crashes.

Hopefully that all makes some sort of sense to what you're asking.

-dro

7
I don't remember such an issue being reported before against the current preview build so I have no idea if it's fixed in the betas or not as it's not something I'm so far able to replicate.

I'd need some more information like what the WACUP install type was (normal / portable) & what OS you're using along with if anything was unchecked during installation.

-dro

8
Preview Build Discussion / Re: Big Clock Issue
« on: September 29, 2021, 02:08:23 PM »
Quote
Fixed some font handling related issues with the Big Clock plug-in such as when it's already in double-size mode or if the font selection dialog is cancelled which would reset the font back to generic one until restarting WACUP
There were some issues with the font handling of the plug-in in the preview build so it's likely related to what's been done as part of this fix with the betas otherwise it's not something I've been able to replicate.

-dro

9
General Discussion / Re: Cutting off Songs
« on: September 29, 2021, 02:03:42 PM »
I'd really need more information including what WACUP version is being used (the choice of wording makes me think that a WACUP install isn't being used) also including what happens if the crossfading as provided by the output plug-in is completely disabled.

The mention of it happening around the 6min mark is also somewhat odd & could even imply something related to the files being used. I also don't quite follow if this is a hard-cut off or if it's still a related crossfade that's happening but at that time point.

-dro

10
Skins / Re: Displaying the active Playlist Title
« on: September 29, 2021, 01:58:40 PM »
There's no ability for anything to do this as once something's added into the main playlist editor (which is better thought of as a temporary queue / scratch list), there's no context of where those items have come from.

It's something that has cropped up numerous times over the years based on how other players seem to hide all of it away & track things which Winamp never has & I've yet to figure out how best to do it whilst working within some of the compatibility aspects that I've got to hold to.

-dro

11
Wishlist / Feature Requests / Re: G-force Visualisation
« on: September 29, 2021, 01:45:35 PM »
Can you point me at what copy / version of the plug-in you're trying to use please. Also what have you done so far to try to use the plug-in with WACUP?

As it should be able to run without any issue as long as it's been able to be installed correctly into WACUP & that you're either running in a normal WACUP install or if it's a portable install that the option on Preferences -> Advanced -> Portable to allow for 3rd party plug-ins has been enabled.

-dro

12
Wishlist / Feature Requests / Re: Spotify integration
« on: September 29, 2021, 01:42:34 PM »
Obviously this project was based on Winamp.
It didn't use anything from Winamp & an incomplete portion of the source code for it was released - it wasn't released with the internal library that spotify used along with something else iirc which for the most part made it an ultimately pointless source code release.

libspotify & librespot are the only possible options that I'm aware of (the first one one is massively deprecated as I've mentioned previously) but as not being a spotify user (never actually used it) I don't know how well trying to integrate such support would even go with it more likely end up that it'd just make WACUP be a glorified controller than actually doing the proper playback. I know I probably need to look into this but it also feels at odds with WACUP being more aimed towards working with a local library of files.

-dro

13
Preview Build Discussion / Re: Won't play CD Audio?
« on: September 29, 2021, 01:36:05 PM »
Edit: The plugin starts out as disabled.  This seems like a bad idea, but I'm posting this to hopefully be of use to someone else.
The main reason is that most don't even have CD/DVD/Bluray drives present & having the plug-in always be loaded & the overhead it introduces just didn't seem beneficial. That's why I've gone with it being installed but disabled by default with the naive assumption that a user will then have a look in the preferences to find that the input plug-in is there but not enabled & just toggling the enable option to get it running.

I've yet to come back to working on my audio cd plug-in as it's overall a low priority & it's likely I can probably try to do more based on what I've learnt from the past year or so with asynchronous handling of things that'll help to reduce it's impact on loading which for a real drive (less so with virtual drives) can cause the whole process to hang for a noticeable amount of time on load which wasn't something I found to be acceptable (hence disabled by default).

I get that for those needing it it's not the best of decisions but everything has to be balanced out between what makes sense vs what's the lesser evil for WACUP as a whole.

-dro

14
General Discussion / Re: Milkdrop on system audio?
« on: September 29, 2021, 01:17:48 PM »
I've already noted above that it's on my todo list & will eventually get added, it's just not a high priority for me to implement for the moment with the on-going issues with the replacement local library plug-in & getting WACUP to not rely upon the original Winamp program file to run.

It'll get done eventually & I've got test code already that seems to do what I'd want (with it handling audio capture when using USB speakers which isn't something the existing linein:// method is able to handle correctly) so I probably don't need to consider looking at beatdrop (not sure if it's even licensed in a compatible manner that'd allow me to use it's aspects even if I was going to go that route).

-dro

15
Preview Build Discussion / Re: How To Play CD?
« on: September 29, 2021, 01:13:27 PM »
Depending on what you were doing, the undo playlist action in the main playlist editor window (better thought of as a temporary queue / scratch list vs what the media library playlists are like) can also be a simpler way to get things back to what had been there prior to what has been set be it loading an audio cd or another playlist, etc if that's what is wanted. Otherwise just add more items into the main playlist however you prefer be it internally or externally.

-dro

Pages: [1] 2 3 ... 82