Author Topic: xmp-openmpt: An XMPlay input plugin based on OpenMPT  (Read 172544 times)

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #350 on: 31 Dec '24 - 14:42 »
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

  • Posts: 80
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #351 on: 31 Dec '24 - 15:05 »
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.
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

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #352 on: 1 Jan '25 - 23:26 »
First 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

  • Posts: 80
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #354 on: 6 Jan '25 - 16:54 »
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

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #355 on: 8 Jan '25 - 17:17 »
Instrument 2 with filter envelope isn't played accurately.
Instrument envelopes with the "carry" flag set are no longer reset after a note-off in the latest build.

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #356 on: 12 Jan '25 - 10:48 »
This and this MED are not played properly.