xmp-openmpt: An XMPlay input plugin based on OpenMPT

Started by saga,

Reply Print
Go Down Pages 1 ... 16 17 18 19 20

saga

#340
If you turn off volume ramping, some clicks can be heard because there is a bass sample that is retriggered constantly and each time it retriggers, it is at a very high point. Volume ramping is exactly meant to reduce clicks like these.

saga

#342
Last Edit: by saga
Portamento behaviour should be more in line with OctaMED now.

manx

#345
Last Edit: by manx
2024-12-01: xmp-openmpt version 0.7.12 released!

 *  [**Bug**] Fixed various undefined behaviour found with ubsan.

 *  IT: Don't report files claiming to be made with Impulse Tracker 2.08+ as IT-made if they have no edit timer.
 *  IT: Ignore sample data in slots that don't have the "sample data present" flag set, if the file vaguely looks IT-made to avoid playing garbage caused by an Impulse Tracker bug that should not be audible.
 *  S3M: Detect early Schism Tracker versions.
 *  MOD: When trying to detect MOD files with broken order lists, the file size is now rounded down to an even number. This helps identifying some malformed files (MOD files can technically not have an odd size).
 *  MOD: Also enable ProTracker-compatible tremolo ramp waveform for M!K! modules.
 *  MOD: In ProTracker 1/2 mode, retrigger with instrument-less notes now keeps using the previous sample offset.
 *  Warn when a Startrekker AM file most likely requires an (currently unsupported) external instrument definition file.
 *  DBM / IMF / MED: When merging pattern commands, allow to move offset to volume column at the expense of a lower offset resolution.
 *  MED: Fix correct octave transposition in some MED files that have hardware mixing disabled but sample transpose enabled.
 *  MED: Don't enable Amiga resampler if any stereo samples are found, as it does not support stereo samples.
 *  MED: Fix tempo in some files using software mixing mode and legacy tempo values.
 *  MED: Avoid importing effect memory for some commands.
 *  MED: Retrigger with instrument-less note now keeps using the previous sample offset.
 *  MED: Disable sample swapping on notes with portamento, and don't resume stopped notes with portamento.
 *  MED: Only use 7-bit volume commands in MMD3 files made with a new enough version of MED Soundstudio.
 *  STM: Do not sanitize sample loop data. Scream Tracker 2 reads into the next sample's data when loops exceed the sample length.
 *  When evaluating MIDI macros containing letters "u" or "v" during seeking, the initial global volume was applied to them, rather than the global volume that would be reached at that pattern position.

 *  mpg123: Update to v1.32.9 (2024-11-02).

See https://lib.openmpt.org/libopenmpt/2024/12/01/releases-0.7.12-0.6.21-0.5.35-0.4.47/

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)

guest

#347
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.

guest

#348
When Volume Ramping is off, the plugin seems to play as if the FT2 Config -> Mixing device ctrl. -> Vol. ramping option was still enabled, e.g. instrument 3 on 7th channel is washed out.

manx

#349
Quote from: guestWhen Volume Ramping is off, the plugin seems to play as if the FT2 Config -> Mixing device ctrl. -> Vol. ramping option was still enabled, e.g. instrument 3 on 7th channel is washed out.

This is by design. Original DOS FT2 dos not have the setting you mentioned and always plays it with FT2-style volume ramping. The setting was only added in the FT2 port to modern systemsby 8bitbubsy. OpenMPT and  libopenmpt treat FT2-stype volume ramping as an original-tracker playback behaviour feature. In OpenMPT, these can be disabled (in order to facilitate conversion to other and more modern playback behaviours and/or other formats), however, libopenmpt in general does not offer tuning individual playback compatibility flags (this would be hundreds of options). libopenmpt does not enable that compatibility flag for XM modules which have been saved by other trackers than FT2 that do not implement FT2-style volume ramping (as far as detecting the other trackers is possible, if it is not possible, the format-defining tracker (i.e. original FT2) is assumed). The goal here is to play modules as much as possible as they sounded in original FT2, and in particular not as they sound in players that to not mimic the extra-soft volume ramping of FT2, which makes most XM modules not sound as intended, IMHO.

So, this is not a bug. It may be possible to make an argument whether disabling volume ramping in general should affect this particular FT2 compatibility flag, but that would better be discussed in our issue tracker at https://bugs.openmpt.org/.

guest

#350
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

#351
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

#352
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

#354
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

#355
Quote from: guestInstrument 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.

saga

#357
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

#359
Seems like FFF commands should only cut notes if they are not triggered on the same row. Should be fixed.
Reply Print
Go Up Pages 1 ... 16 17 18 19 20