View Issue Details

IDProjectCategoryView StatusLast Update
0001269OpenMPTPlayer input plugins (xmp-openmpt, in_openmpt)public2022-02-16 17:39
Reportermanx Assigned Tomanx  
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Product VersionOpenMPT 1.29.00.* (old testing) 
Target VersionOpenMPT 1.?? (libopenmpt 1.0) (goals) 
Summary0001269: remove in_winamp
Description

libopenmpt is now used by the 2 major winamp distributions:

We should consider removing in_winamp from libopenmpt completely.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

Saga Musix

Saga Musix

2019-10-11 13:49

administrator   ~0004106

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.

Saga Musix

Saga Musix

2019-10-26 15:50

administrator   ~0004119

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.

manx

manx

2019-11-02 13:59

administrator   ~0004135

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)

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

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

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.

manx

manx

2020-07-26 13:45

administrator   ~0004407

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

dro

dro

2022-02-15 14:28

reporter   ~0005088

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

Saga Musix

Saga Musix

2022-02-15 20:23

administrator   ~0005089

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?

dro

dro

2022-02-16 12:12

reporter   ~0005092

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

manx

manx

2022-02-16 16:00

administrator   ~0005095

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.

Issue History

Date Modified Username Field Change
2019-10-11 13:27 manx New Issue
2019-10-11 13:27 manx Status new => assigned
2019-10-11 13:27 manx Assigned To => manx
2019-10-11 13:49 Saga Musix Note Added: 0004106
2019-10-11 14:28 manx Target Version OpenMPT 1.29.01.00 / libopenmpt 0.5.0 (upgrade first) => OpenMPT 1.?? (libopenmpt 1.0) (goals)
2019-10-26 15:50 Saga Musix Note Added: 0004119
2019-11-02 13:59 manx Note Added: 0004135
2020-05-24 19:25 manx Category Player input plugins (xmp-openmpt, in_openmpt, foo_openmpt) => Player input plugins (xmp-openmpt, in_openmpt)
2020-07-26 13:45 manx Note Added: 0004407
2021-11-20 09:17 manx Target Version OpenMPT 1.?? (libopenmpt 1.0) (goals) => OpenMPT 1.31 / libopenmpt 0.7 (goals)
2022-02-15 14:28 dro Note Added: 0005088
2022-02-15 20:23 Saga Musix Note Added: 0005089
2022-02-16 12:12 dro Note Added: 0005092
2022-02-16 16:00 manx Note Added: 0005095
2022-02-16 17:39 manx Target Version OpenMPT 1.31 / libopenmpt 0.7 (goals) => OpenMPT 1.?? (libopenmpt 1.0) (goals)