Topic: xmp-openmpt: An XMPlay input plugin based on OpenMPT

[guest]

This MED sounds different even than in MED Soundstudio for Windows.

[saga]

This MED sounds different even than in MED Soundstudio for Windows.

One day I will understand all of this MED mess... Right now I'm not entirely confident what the correct fix for this is, but I will keep investingating.

Also...

• bugfixed (the song).ptm
  Starting at 2:26, PolyPlayer plays bass deeper.

I reverted this "fix", apart from the use of square root pan law. The fact that the bass is louder in PolyTracker and PolyPlayer is a DOSBox bug, which I ran into before and completely forgot about. In DOSBox-X, the bass plays at the correct volume and panning.

[guest]

⁍ This OKT hasn't sound after 3:48 in Oktalyzer.

⁍ This PTM should have sound starting from 0:08.

⁍ This ULT is played too slow - duration in Ultra Tracker is about 5:10

⁍ This DMF seems to be played a little too slowly - duration in X-Tracker is about 12:51

[manx]

2024-09-22: xmp-openmpt version 0.7.10 released!

 *  [**Change**] FST was added to the list of supported file extension. AMP uses
    this extension for multichannel MODs.

 *  [**Bug**] The Android NDK build system did not enable C++20 when available.

 *  Fixed inconsistency in length calculation and actual playback length with
    tempo commands below 32 BPM in various formats (MDL, MED among others).
 *  MED: Command 09 (set speed) was limited to 20 ticks per row instead of 32
    ticks per row.
 *  MED: Allow tempo parameters < 32 BPM.
 *  MED: Disallow free panning if hardware mixing is enabled.
 *  MED: For MOD-style vibrato, a speed parameter of 0 was not treated as effect
    memory. Vibrato speed is now correct for both vibrato commands.
 *  MED: Fix pattern index exhaustion in modules with multiple subsongs.
 *  OKT: Don't drop global commands when setting paired channel volume, and try
    to write channel volume on the next row in this situation.
 *  PTM: Use square root pan law, like in XM files.
 *  SFX: Ignore unused data at end of oneshot samples which sometimes caused
    clicky noises.
 *  SFX: More accurate implementation of arpeggio effect.

 *  mpg123: Update to v1.32.7 (2024-08-07).

See https://lib.openmpt.org/libopenmpt/2024/09/22/security-update-0.6.19-releases-0.7.10-0.5.33-0.4.45/

Downloads:
 * xmp-openmpt for Windows 10 21H2 (or later) and SSE2-capable CPU, or legacy version for Windows 7 SP1 (or later) and SSE2-capable CPU
 * xmp-openmpt RETRO for Windows XP SP3 (or later) or non-SSE2-capable CPU
 * xmp-openmpt RETRO for Windows 98 SE + KernelEx (or later) (without configuration dialog)

[saga]

⁍ This OKT hasn't sound after 3:48 in Oktalyzer.

⁍ This PTM should have sound starting from 0:08.

⁍ This ULT is played too slow - duration in Ultra Tracker is about 5:10

These should all be fixed.

⁍ This DMF seems to be played a little too slowly - duration in X-Tracker is about 12:51

I found that X-Tracker's sometimes is inconsistent and plays a bit too fast. Maybe that's what you observed. A test module with a perfectly looped drum loop created in X-Tracker also plays with perfect looping in OpenMPT.

[guest]

• Plugin reports duration of 6:32 but but the playback stops at 3:36.

• On channels 3 and 6 in the first position, there is no sound interruption in Oktalyzer.

[saga]

• On channels 3 and 6 in the first position, there is no sound interruption in Oktalyzer.

This was caused by the previous Oktalyzer fix.. why of course people are abusing the edge cases of this tracker's weird playback in all possible ways. Should be fixed now.

• Plugin reports duration of 6:32 but but the playback stops at 3:36.

This one (correct song length estimation when there's a pattern delay on the same row as a pattern loop) is currently pretty difficult to fix. I'm not sure if it can be fixed at all until https://bugs.openmpt.org/view.php?id=1814 is implemented.

[guest]

‣The first position, especially from row 32 is played differently in Oktalyzer.

[guest]

‣Symphonie Pro 3.3 plays differently eg. at 0:03, 0:07, 0:30, 0:44 and from 1:21 (on channels 18 and 19).

[saga]

‣The first position, especially from row 32 is played differently in Oktalyzer.

I'm not sure if this can be fixed easily at the moment. In Oktalyzer two adjacent mixed channels share the same volume, which OpenMPT implements by cloning volume commands from one channel to the other. In this case (and as with most other Oktylzer bugs you reported) this means that such volume updates may overwrite other pattern commands, and while it was possible in other cases to work around this (e.g. by moving speed commands to another channel), here the volume commands overwrite some pitch slides that need to stay on the same channel. With the current OpenMPT architecture, I don't think there is an easy way to get this right.

‣Symphonie Pro 3.3 plays differently eg. at 0:03, 0:07, 0:30, 0:44 and from 1:21 (on channels 18 and 19).

Somehow it seems like the highpass filter is not acting as a highpass filter at all in Symphonie. Which is strange, because I can't find any issues just from reading the assembly code, the highpass filtering code is clearly there and should be called. This will need more analysis.

[guest]

Unrecognized SymMOD

[saga]

That file uses more channels than OpenMPT currently supports internally. I have modified the code so that it no longer outright rejects the file, but the last channel won't be audible.

[guest]

Rejected SymMOD

[saga]

That file has some garbage at the end. One of the samples is also slightly corrupted, so most likely the file is broken. Anyway, unknown garbage at the end is now ignored similar to how Symphonie does it.

[guest]

‣Symphonie Pro 3.3 plays differently eg. at 0:03, 0:07, 0:30, 0:44 and from 1:21 (on channels 18 and 19).

Somehow it seems like the highpass filter is not acting as a highpass filter at all in Symphonie. Which is strange, because I can't find any issues just from reading the assembly code, the highpass filtering code is clearly there and should be called. This will need more analysis.

Symphonie Pro 3.3d at 0:03, 0:07 seems to sound similar to the plugin, but there are still differences at 0:30, 0:44 and from 1:21 on channels 18 and 19.

[saga]

OpenMPT needs to map all the filter commands to one of the 128 fixed MIDI macros. Until now it just stopped applying MIDI macros once there were more 128 of them, now it tries to find the closest matching macro instead, which should play the file a bit more faithfully.

[guest]

Still no filtering can be heard on channels 18 and 19, starting from position 23.

[saga]

Yes, as mentioned OpenMPT is running out of MIDI macros to assign to the different filter settings. Previously it didn't apply any filtering at all, now it manages to apply at least one fixed filter setting instead of nothing at all.

[manx]

2024-10-26: xmp-openmpt version 0.7.11 released!

 *  IT: Don't import SAx High Offset command for IT 1.xx modules. This feature was added in Impulse Tracker 2.00.
 *  IT: Limit Vxx parameter to V80 for files made with old Schism Tracker versions.
 *  IT / S3M: Impulse Tracker 2.14 patch version information was incorrect.
 *  S3M: O00 effects are no longer ignored if the tracker version in the file header indicates Scream Tracker 3.00 / 3.01, but the file was clearly saved with another tool (e.g. UNMO3).
 *  S3M: As files made with Scream Tracker 3.20 and 3.21 cannot be told apart, both versions are now listed in the tracker metadata.
 *  ULT: Try to preserve global commands if there's e.g. both a speed and tempo command in the same cell.
 *  STM: Improved tracker identification metadata.
 *  SymMOD: When running out of Zxx macros, try to find the closest macro to use instead.
 *  SymMOD: Ignore unknown hunks instead of rejecting entire file, as that's what Symphonie does as well.
 *  OKT: Disable loop on type "B" samples if they're used on a mixed channel.
 *  OKT: The last sample slot was never loaded.
 *  PTM: Halve offset command strength for 16-bit samples.

 *  mpg123: Update to v1.32.8-dev+r5433 (2024-10-24).

See https://lib.openmpt.org/libopenmpt/2024/10/26/releases-0.7.11-0.6.20-0.5.34-0.4.46/

Downloads:
 * xmp-openmpt for Windows 10 21H2 (or later) and SSE2-capable CPU, or legacy version for Windows 7 SP1 (or later) and SSE2-capable CPU
 * xmp-openmpt RETRO for Windows XP SP3 (or later) or non-SSE2-capable CPU
 * xmp-openmpt RETRO for Windows 98 SE + KernelEx (or later) (without configuration dialog)

[saga]

There are still missing sounds in "toki - 5", compare e.g. with https://www.wothke.ch/playmod/?file=/MODLAND/Pumatracker/Pierre-Eric%20Loriaux/toki%20-%205.puma&emulator=UADE.

This should now finally be fixed. And speaking of synthesized formats, Future Composer support has also been added in the latest test versions. I did work very closely with the disassembly of the original player, so hopefully most quirks should be emulated correctly, but I only listened to a handful of actual tunes so far, so it's possible that some of them don't play quite right yet.

[saga]

This MED sounds different even than in MED Soundstudio for Windows.

This is now fixed, and hopefully doesn't break any other modules (given that it's OctaMED, that is highly unlikely though )

[guest]

There are differences in the playback of this FC13 module at 0:07-0:09, 0:10-0:12, 0:13-0:14 and 1:11-1:16 (instrument 6 in position 28, 29).

[saga]

Oops, I tested a couple of files exposing the same problematic notes and they were fine during development, seems like I changed something towards the end that broke them. Those notes should work correctly again.

[guest]

This MED sounds different even than in MED Soundstudio for Windows.

This is now fixed, and hopefully doesn't break any other modules (given that it's OctaMED, that is highly unlikely though )

Plugin does not play bassdrum starting from 1:09.

[saga]

I hear the bass drum just fine here with the latest version. It happens to be affected by the same bugfix I made for the Future Composer file.