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.