xmp-openmpt: An XMPlay input plugin based on OpenMPT

Started by saga,

guest

Ok, Fasttracker v2.08 has only "16-bit mixing" config option (without "+Vol.ramping") but when this option is disabled, instrument 3 is more audible in FT2.

manx

Quote from: guestOk, Fasttracker v2.08 has only "16-bit mixing" config option (without "+Vol.ramping") but when this option is disabled, instrument 3 is more audible in FT2.
We cannot emulate every minute detail of the mixing behaviour of all trackers in their non-optimal configuration. This would frankly be another hundreds of options and unmaintainable. FT2, when configured for optimal sound quality, and in its latest/final version, does exhibit the ultra-soft volume ramping, and without it, almost all XM modules made with FT2 (as far as it is possible to reliable detect that) do sound wrong.

Again, there might be an argument made for disabling that behaviour if volume ramping is completely disabled (which is frankly not a very useful configuration, to be honest), but this would not be a change that would be made in a minor version update (if at all). If you care enough, please move this discussion to our issue tracker and make a ticket.

saga

Quote from: guest
Quote from: saga
Quote from: guestFirst channel in 10th order starting from row 28 is played differently in OctaMED.

...should play correctly now. Let's see what this breaks...

When "Use Amiga resampler for Amiga modules" is enabled it plays as in MED Soundstudio for Windows, not as in OctaMED for Amiga.
The sample resampling algorithm does not make any difference in things like this. I accidentally inverted the condition when the fix should be applied, now it is corrected.


manx

2025-01-06: xmp-openmpt version 0.7.13 released!

 *  `module::get_current_estimated_bpm` could return infinity when rows per beat was set to 0. A default of 4 rows per beat is now assumed in this situation. The internal LFO plugin was also affected in Tempo Sync mode.
 *  Instruments that have a MIDI channel assigned and NNA set to "Continue" could cause NNA channel starvation.
 *  In non-compatible linear slide mode, the sample rate could wrap around with portamento slides to extremely low frequencies. This should only happen in compatible mode.

 *  mpg123: Update to v1.32.10 (2024-12-14).
 *  XMPlay SDK: Update to 2025-01-03.

See https://lib.openmpt.org/libopenmpt/2025/01/06/releases-0.7.13-0.6.22-0.5.36-0.4.48/

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



saga

Quote from: guestThis and this MED are not played properly.
It took a while to figure out, but transposed IFFOCT instruments in MED files should now behave more correctly.


saga

Seems like FFF commands should only cut notes if they are not triggered on the same row. Should be fixed.