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.