Latest WACUP beta release is build #9478 (November 30th 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 ... 85
It is possible to change the order by clicking on the root view headers but specific re-ordering is something I'd need to look into as currently drag+drop is setup to interact with the existing playlists instead of allowing for moving.


Wishlist / Feature Requests / Re: shared library accross computers
« on: November 24, 2021, 10:31:09 PM »
Not sure why it was done like that other than ease of parsing a single file but it's a behaviour I've got to maintain as I know there's some tooling out there that expects it.


Wishlist / Feature Requests / Re: Media Library Views Settings
« on: November 23, 2021, 01:40:24 PM »
I'm talking about the view configuration files that are currently saved in the users data 'WACUP/Plugins/ml/views' folder. I should mention that the current behavior pre-dates WACUP. Would WACUP object to making these files read-only after they are setup as desired? When making a desired change, a pop-up could be used to alert the file's read-only state. Similar to what happens when attempting to save metadata edits in a read-only audio file.
I know it's those files you're referring to but they're used also for storing the current sorting state & a few other things so setting them to read-only can then break some aspects which if someone just toggles options however (as some do) & then wonder why it's not working. Adding in more pop-ups gets more confusing easily but it probably would be the only sane way.

These files would be the default for any new skin, as they are now. Then once the library window in a skin is used (with or without changing it's setup) a new set of these files (or what is in them) would be saved for each skin.

My favorite modern skin has a control that lets the media library window be switched to a fullscreen mode. I then adjusted the column widths (when allowed) within the default and custom views I use to let all or most of the metadata strings for each column to be seen. The column widths within some of the views I setup for this skin are sometimes made narrower when switching to another skin that doesn't support a fullscreen mode for the library window (this is mostly a modern and cPro skins issue). It won't be so bad if the column widths stayed at what I set them to. Then I could simply use horizontal and vertical scroll bars to view everything within smaller library windows. When the column widths are narrowed, their metadata strings are truncated to much and I have to readjust the affected columns. I've not been able to determine what triggers these column width changes. It doesn't happen all the time and some views are not affected.
Switching the skin shouldn't be changing the column widths & what's then seen unless it's using a different font to display things - that's the only thing I can explain why it'll then change.

It would be nice to not have to switch to my favorite skin just to use the library without having to sometimes readjust things.

I get your point about the studio.xnf file. I was mainly thinking of keeping the number of files that would otherwise be needed small. It does frustrate me when I have to nuke the studio.xnf file just to fix corrupt configurations for 1 skin or update the configurations when a new version for a skin is released. New skin versions will often add stuff, but never remove stuff that is no longer needed. I do realize that new skin versions are not able to clean up what is no longer needed, so the occasional nuke is not always a bad thing, but I never like doing it.
I know what you're trying to achieve & it does make sense. I just need to get to a position to try out something towards it as I don't know how well it might work in reality vs expectations. As thinking about it a bit more I could just have it only use the current vmd files & with the proposed mode use the existing default values & then save out a new section if the new option was enabled which will then be used subsequently & hope you don't use enough skins to make those files grow to the 64KB limit & then start to break :) Doing things in general with default local library views is something that probably needs some additions anyway since it was never that well configured & is now what I've been able to figure out from reverse handling of the files that ml_local created to allow ml_ll to support them with the changes.


Wishlist / Feature Requests / Re: Managing Smart Views
« on: November 23, 2021, 01:28:57 PM »
I've not done anything towards such things yet though with the current state of what's used with the betas as of this post, I'm only using my plug-in implementations for the library core & the majority of the library plug-ins so attempting to do things with the library navigation list is going to be simpler.

If I understand things correctly from this & other comments about it, what's being wanted is sub-nodes or something akin to an explorer hierarchical tree so from the example it can be something like the following (where each - represents a new sub-level):

local library
|- 1980s
|-- 1989
|--- pop
|--- rock
|-- 1988
|- 1960s
\- others

Is that correct or am I not getting the intention?

Another idea which I've just had is that instead of filling the navigation tree with a load of nodes, I do something more like the playlists root view (which itself has a request for sub-nodes) & then it's done all within there with it's own list/tree of nodes & then the selected view is shown along with it. The only issue is how weird it might look but it's another possible option for me to consider & might for some be more useful anyway seeing as there's only the means to view one local library view at a time (which I'm still toying over maybe allowing multiple views to be seen).


Wishlist / Feature Requests / Re: shared library accross computers
« on: November 23, 2021, 01:17:53 PM »
@zackbuffo: it's usually <wacup_settings_folder>\plugins\ml\views e.g. %appdata%\wacup\plugins\ml\views (normally install) or wacup\settings\plugins\ml\views (portable install)

however you also need the gen_ml.ini as that defines what local library smart views are shown.

@Benco: that was my thought as well but the live concurrency issue is the problem (same for the problems that occur with running multiple instances from the same WACUP install).


Skins / Re: Defix Hi-End (skin) v2.0 (Last updated: November 22nd 2021)
« on: November 22, 2021, 02:42:00 AM »
First post of the thread has now been updated to provide v2.0 of the skin, enjoy & don't forget to thank Denis!


Nothing that's being done nor shown off is imho a surprise. The lot that own Winamp & SHOUTcast are about how to sell TargetSpot adverts & how to make money, no more no less. They also made it quite clear that classic Winamp wasn't going to continue (it died in June 2014 in my eyes) & I was told I was too stuck in the past & that the streaming stuff is what people want.

Maybe it is the only way to go nowadays but like you note, if you're still using Winamp now, you're not really going to be into the things that have made many more move to other services. Either way, their product, their choice & likewise I'm going to keep doing WACUP as that's what works for me & hopefully is beneficial to others.


Seems we can thank this person for some of that slowness...


At least there was a WACUP mention for a change but they've lied about things happening for almost 8yrs though there might be some legitimacy this time around but everything they've said gives me no interest to want to try it out if it does ever appear.

I'll just stick with being a dinosaur in my 'classic' winamp-like world as that's what I want & am highly doubtful their never version is going to be anything Winamp-like in nature (when they're using a new logo that's almost SS-like in style, I don't get good vibes let alone their new website taking over 10seconds to load for me) & just get on with keeping WACUP going :)

Am also sure there'll be loads that'll lap up whatever they offer & it's probably going to cause this project issues but whilst there's enough support & interest then I'll keep going with it.


Wishlist / Feature Requests / Re: shared library accross computers
« on: November 16, 2021, 06:50:32 PM »
I've had a similar thing mentioned before though that was looking more at everything but I'm not sure on a clear way to achieve this without needing some intermediary to do it or it being slow however its done.

As you ideally only need to copy the core library db & the playlists & the files defining the smart views which is simple enough to bundle up but it's then ensuring the correct version is used without it replacing a newer version &/or when things are out of sync. At least you've got the same filepaths between the setups as that makes moving things over a lot easier.

Am surprised it's being unresponsive if loading it from the drive - I'd expect it to be slow for the initial process loading as it needs to fetch the dlls, etc but once running then it shouldn't be hanging, etc (unless I'm mis-reading what you meant).

The only thing I can think off at the moment would be to make it easier to export just the files needed from one setup & allow them to be imported into another setup probably via some command-line option (which moves it into a backup/restore scenario which I've been thinking about doing natively as the more I do the more the Winamp targetted tool becomes less useful).


Why should I consider using what appears to have been abandoned around a decade ago which is also licensed in a manner that I'm not too happy with ? As there's also which I recently was made aware of & is slightly more permissive in it's licensing & is a known quantity from the pacemaker Winamp dsp plug-in that it's derived from.


General Discussion / Re: WACUP can't connect to a stream Winamp plays fine
« on: November 13, 2021, 12:48:58 AM »
You'll have to use the 5.8 beta then as I refuse on principle to install it & I can't offer an eta for when I'll have my replacement plug-in implemented.


General Discussion / Re: WACUP can't connect to a stream Winamp plays fine
« on: November 12, 2021, 09:13:40 PM »
I can't get WACUP nor a plain 5.666 install (the only Winamp install I have installed) to play it & it seems to be due to an enforced use of the HTTPS version of the stream from the Icecast server that is providing the stream. Alas I don't know enough about Icecast to know if there's a parameter or something else I can set to help it provide an HTTP only version of the stream.

Currently I'm not near to having even a basic solution available to be able to drop the in_mp3 plug-in from 5.666 which WACUP is still reliant upon using for such stream playback & it's that plug-in which is ultimately responsible for the lack of working HTTPS support needed to play such streams.


Wishlist / Feature Requests / Re: Media Library Views Settings
« on: November 04, 2021, 03:13:24 AM »
Are we talking just the local media library views or the library window (navigation vs view area ratio) or both & all other potential library views (e.g. history, podcasts, etc) ?

The main thing that concerns me is how jarring it might be when the views are jumping over the place depending on the rate of skin loading / switching along with what happens if you've linked it against a certain skin & then it's updated but it's got a slightly different name which for the simple way of doing this it'd just be on the skin name & then the customisation would be potentially be lost. The other thing is what's used as the fallback if it's the first time of using the skin (i.e. just use the current values or assume some other default).

I get what you're wanting to achieve & can see that it has merit, it just depends a lot on the scope & how much change is actually required to deal with it along with how the plug-in(s) it relates to need to see updates. Also studio.xnf isn't the best of examples as that's also equivalent of winamp.ini & how almost everything gets dumped into it which often makes it a mess (studio.xnf really needs to be done a on per-skin basis so one skin going wonky doesn't require nuking the file & breaking all of the skin configurations made).


General Discussion / Re: Odd Question to DrO
« on: November 03, 2021, 10:08:06 PM »
I don't know why the AMP MP3 decoder library was called AMP. Just that it was then used as part of the software name after having been done with the DOS version as I understand it.

Just found which implies AMP is Advanced Multimedia Products


Pages: [1] 2 3 ... 85