I'm not sure this is a good idea at this point. Winamp 5.8 was more or less only released because it was previously leaked, and from what is known there is no intent to further provide any official updates to Winamp 5. This means that Winamp users would have to stick to an unfinished in_mod rewrite with severely reduced functionality (from what I remember, the settings dialog is missing entirely) and very outdated libopenmpt version.

I also couldn't find any repository for the in_openmpt version shipping with WACUP (I suppose it would be at https://github.com/WACUP/ if it existed), meaning that we would either leave people with an outdated version if we stop updating our plugin, or they would have to rely on a closed-source plugin.

I think this only makes sense if we ask dro if he intends to keep in_openmpt updated and open-source, and if it can be used with Winamp 5.666 / 5.8.

To reduce maintenance burden, maybe we could also make our player plugins use a dynamic version of libopenmpt that can be replaced by the user. This way the plugin itself could be treated as an external project that only needs to be updated if there are breaking API changes or new useful features are introduced.

I do not think changing the way we build in_openmpt changes anything with regard to maintenance. To the contrary, splitting would in turn increase support overhead.

Currently available Winamp versions:

Winamp 5.666 Build 3516 (5.6.6.3516) (2013-12-12)

• http://forums.winamp.com/showthread.php?t=373755
• old stable release, unmaintained
• uses mikmod

Winamp 5.666 redux Build 3516 (5.6.6.3516) (2013-12-25)

• http://forums.winamp.com/showthread.php?t=373755
• based on Winamp 5.666 Build 3516 (5.6.6.3516)
• latest stable release, not updated in 6 years, thus probably unmaintained
• uses mikmod

Winamp 5.8 Beta Build 3660 (2018-10-19)

• http://winamp.com/ / http://forums.winamp.com/showthread.php?t=453675
• based on Winamp 5.666 Build 3516 (5.6.6.3516)
• latest beta release, not updated in 1 year, for sure unmaintained ("This version is not an ongoing project but be sure that we are currently working hard on a future new Winamp.")
• uses libopenmpt 0.2

Winamp 5.666 WACUP Build v1.0.8.4346 (2019-10-14)

• https://getwacup.com/preview/
• based on Winamp 5.666 Build 3516 (5.6.6.3516)
• fork with beta releases, regularly updated, maintained
• uses libopenmpt 0.4

WACUP provides mostly-up-to-date libopenmpt itself, and all other Winamp branches are most likely dead and unsupported software anyways. I'd rather not continue support for known-dead and known-unsupported other branches.

WACUP now ships libopenmpt 0.5. See https://getwacup.com/preview/preview_1_0_13_5864.html.

Having seen this from github I hope you don't mind me chipping in & I'll try not to ramble too much.

When it comes to updating, when I see a libopenmpt update I apply that to my dev build so the current WACUP beta is based on 0.6.1. The mess with getting out a new WACUP public preview build means what's offered for that is based on 0.5.5.

If you want me to provide all of my changes to the plug-in then I'll do it but they've not been done in a manner that easily backports to use with plain Winamp installs - it can be done but I've tweaked it so it better fits with my needs without being concerned about standalone compatibility. So how useful that'd end up being I don't really know plus I'm no longer in the mind set to want to provide anything that I do which will also work with a plain Winamp install. Unless I stop working on WACUP (unlikely as I'm too deep into this rabbit hole) then I'm going to keep my version of the plug-in updated as I need to have working MOD support as it's quite popular from the feedback I've gotten.

For the plain Winamp plug-in side of things, making the plug-in you offer be in_openmpt.dll + shared library does make more sense but imho it still leaves you with the perceived support burden & the impression I get is you don't really want have to deal with any of that. Plus there's then the users that don't follow the instructions & mess up "installing" it.

As for the incomplete / leaked / abandoned 5.8 beta build (I still hold to them having done it to test the waters &/or just drive a bit of hype for investors), if there's no config dialog then it'll be because they did the minimum to just not have to deal with the MFC dependency to include something.

Either way anything that's based on 'classic' winamp seems to be a dead-end with the recent beta survey's web-based hints & the job listings from the past year that have been found so I wouldn't fault you for wanting to drop providing such a plug-in going forward & instead either leave a legacy version around that's at a reasonable level of feature support &/or just point to any other players that use libopenmpt & not even worry about offering a plug-in.

-dro

If you want me to provide all of my changes to the plug-in then I'll do it but they've not been done in a manner that easily backports to use with plain Winamp installs - it can be done but I've tweaked it so it better fits with my needs without being concerned about standalone compatibility

I don't think that would be necessary - especially since the plugin, as it currently can be found in the repository, is more of a Winamp 2.x plugin than a 5.x plugin to increase compatibility with other players. But I noticed that various plugins are already open-sourced at https://github.com/orgs/WACUP/repositories - would anything speak against putting your version of in_openmpt/in_mod there as well?

What's on there is because the licensing required it or I'd forked from what was on github already so it's not against my personal account. I've put it on my todo list to sort out getting my in_mod up there.

-dro

Thanks for your insights, @dro .

Looks like my assessment of the situation pretty much matches yours 100%.

As classic Winamp is pretty much dead, there is not really much we could do for users who want to stick to "classic Winamp" even on modern systems. The only remaining obvious use case then for our in_openmpt is basically old systems where modern classic Winamp or WACUP do not even run. However, we also have more and more problems building for such platforms. The version for Win9x that we ship does not even have the configuration dialog.

I guess we could keep in_openmpt basically in feature-freeze, until it causes further build problems.

So, it looks like winamp.com now decided that the old code base is undead again, and Winamp 5.9 RC3 Build 9999 ships a current libopenmpt 0.6.4.

The only reason to keep our in_openmpt.dll now is Winamp 2.x users. Not sure if that alone makes it worth it to keep it around.

As of now, lib.openmpt.org lists in_winamp as deprecated and links to Winamp 5.9.0 and WACUP as a replacement. We still provide in_winamp for users of older versions or compatible players.