Updating openmpt input files into WACUP?

[ant]

Is it safe to use the updated https://lib.openmpt.org/files/libopenmpt/bin/libopenmpt-0.5.10+release.bin.win.zip, from https://lib.openmpt.org/libopenmpt/, in WACUP? Or do I need to wait for the official WACUP release?

Thank you for reading and hopefully answering soon.

[dro]

It's as safe as installing any plug-in but with how the input plug-ins are checked for what to use to play things then it's unlikely it'd actually be used over the WACUP provided plug-in without disabling that one first.

-dro

[ant]

It's as safe as installing any plug-in but with how the input plug-ins are checked for what to use to play things then it's unlikely it'd actually be used over the WACUP provided plug-in without disabling that one first.

-dro

Wait. How do I know what plugin is used to play MOD, XM, IT, S3M, 669, etc.? I see the default OpenMPT Module Decoder v0.5.5.4 is checked. FYI. This is an over month old WACUP installation on my eight weeks old new 64-bit W10 Pro PC. So, it should be mostly defaults.

[Aminifu]

Open the WACUP Preferences and scroll down to the Advanced section (bottom on the left) and select the Diagnostics group. Then select the File Associations tab in the Diagnostics group. This tab should list most of the file types associated with the active (checked) input plug-ins. Some input plug-ins do not directly report the file types they handle. However the ones you're interested in should be listed.

[dro]

You can't easily see what input plug-in is going to be used when there's multiple plug-ins trying to claim a file type (what aminifu has noted whilst I'd started to reply sort of helps but there's no conflict reporting nor does it show the actual query order of the plug-ins).

The way that things currently work means the first plug-in queried that reports it wants a file type will be the one that gets to handle & that's biased towards the WACUP plug-ins since they're loaded before any 3rd party plug-ins get loaded i.e. WACUP's in_mod will be loaded before the openmpt provided in_openmpt.

The preview build hasn't been updated since March which is why it's on an older revision of libopenmpt - it's been thrown about maybe allowing for inter-build updates for some of the plug-ins but that's not been thought about for a while. It's now going to be at some point in August at the earliest that a newer preview build is going to be offered which will have the latest libopenmpt update included when that occurs (the current beta is already using 0.5.9 with the next one to use 0.5.10 as I'd not seen they released the newer version until just after I'd done a new beta build on the same day).

-dro

[ant]

Open the WACUP Preferences and scroll down to the Advanced section (bottom on the left) and select the Diagnostics group. Then select the File Associations tab in the Diagnostics group. This tab should list most of the file types associated with the active (checked) input plug-ins. Some input plug-ins do not directly report the file types they handle. However the ones you're interested in should be listed.

OpenMPT Module Decoder v0.5.5.4 [in_mod.dll] show them.

[ant]

You can't easily see what input plug-in is going to be used when there's multiple plug-ins trying to claim a file type (what aminifu has noted whilst I'd started to reply sort of helps but there's no conflict reporting nor does it show the actual query order of the plug-ins).

The way that things currently work means the first plug-in queried that reports it wants a file type will be the one that gets to handle & that's biased towards the WACUP plug-ins since they're loaded before any 3rd party plug-ins get loaded i.e. WACUP's in_mod will be loaded before the openmpt provided in_openmpt.

The preview build hasn't been updated since March which is why it's on an older revision of libopenmpt - it's been thrown about maybe allowing for inter-build updates for some of the plug-ins but that's not been thought about for a while. It's now going to be at some point in August at the earliest that a newer preview build is going to be offered which will have the latest libopenmpt update included when that occurs (the current beta is already using 0.5.9 with the next one to use 0.5.10 as I'd not seen they released the newer version until just after I'd done a new beta build on the same day).

-dro

Darn it.

[dro]

If you really need to use the newer openmpt build, disable the in_mod plug-in by un-checking it via the input plug-in preferences page & accept that some aspects are not going to work like they did. The onus is then on you to either to remember to change it back when a newer WACUP build is provided or to keep manually updating the openmpt build of the plug-in.

-dro

[ant]

If you really need to use the newer openmpt build, disable the in_mod plug-in by un-checking it via the input plug-in preferences page & accept that some aspects are not going to work like they did. The onus is then on you to either to remember to change it back when a newer WACUP build is provided or to keep manually updating the openmpt build of the plug-in.

-dro

Well, I just wanted some improvements over the older version. I won't bother since it will lose some aspects.

[Aminifu]

Well from one old timer to another, I'm sure you know that sometimes things advertised as an improvement aren't. Also you know the saying "If it ain't broke, don't fix it".   

[dro]

Well, I just wanted some improvements over the older version. I won't bother since it will lose some aspects.

I get the reasoning & you can give it a go as the core playback should work the same irrespective of the version but I don't know if you're going to need some of the WACUPification that's been done to it vs the generic version that's aimed at working in simpler Winamp compatible solutions.

I do however appreciate that my delay in offering a newer preview build doesn't help things though with what I've seen in the changelogs, most of the things fixed (am somewhat dubious over some of the stated security issues in terms of actually being able to use them maliciously since you still need to have gotten a bad file onto the machine somehow) is unlikely to make a marked difference with a bit more of a wait.

-dro