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

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #275 on: 6 Jul '24 - 22:46 »
There is an inaccuracy in the playback of GMC:

amos.gmc
sample 1 from 0:11

miami chase (plant).gmc
sample 7, 10 from 0:08

zd-breathingvectors-2.gmc
sample 2 from 0:02

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #276 on: 8 Jul '24 - 21:56 »
Oops, loop lengths were treated as bytes instead of words, this should be fixed now.
« Last Edit: 9 Jul '24 - 13:10 by saga »

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #277 on: 14 Jul '24 - 13:52 »
Silly.med
• instrument 6 isn't played accurately eg. at 0:02, 0:05, 0:08, ...
• sounds on channels 3 and 4 aren't cut off at 1:17
• the title should be "Silly", not "Intro"


Jungle_Ballad.med
• long instrument names aren't displayed in full
• the title should be "Jungle_Ballad"

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #278 on: 14 Jul '24 - 15:03 »
• long instrument names aren't displayed in full
Internally, sample or instrument names longer than 31 characters are currently not supported. This may change in the future, but not now.

• the title should be "Silly", not "Intro"
• the title should be "Jungle_Ballad"
If there's only one song in the file, the "global" song title instead of the (potentially automatically determined) subsong title is now used.

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #279 on: 15 Jul '24 - 21:56 »
"Silly" should play more accurately now.

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #280 on: 20 Jul '24 - 12:51 »
MED.Flowing Sky

• Stereo separation cannot be set according to OctaMED Soundstudio.
  The stereo separation slider in the plugin seems to have no effect.

• Instrument J (tonfo) eg. in row 6, 38 on 4th channel of first order
  and instruments on last channel of eg. 23rd, 27th order
  are played too quietly.

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #281 on: 20 Jul '24 - 15:22 »
• Stereo separation cannot be set according to OctaMED Soundstudio.
  The stereo separation slider in the plugin seems to have no effect.
The stereo separation in the plugin has no effect because there is no stereo separation at work here. The file contains a pan table for the individual tracks, which is all-center. The docs don't mention anything about this, but I guess this pan table needs to be ignored when the "free pan" flag is not set for MMD2 files. In MMD3 files it appears that the panning table must be used regardless of the freepan flag.

• Instrument J (tonfo) eg. in row 6, 38 on 4th channel of first order
  and instruments on last channel of eg. 23rd, 27th order
  are played too quietly.
Another one of those undocumented changes between (Octa)MED versions. In MED Soundstudio for Windows, the volume range is 0 to 127 while on Amiga it's 0 to 64. I am not sure if using one or the other interpretation is only up to the format version (MMD2 vs MMD3), so the fix that I applied might be too general.

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #282 on: 21 Jul '24 - 12:11 »
OctaMED Soundstudio V1.03c seems to not open this MMD2 in Mix mode by default (unless "Use Mixing (MMD)" in Miscellaneous Options is switched on) but stereo separation slider in plugin has no effect.

manx

  • Posts: 80
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #283 on: 21 Jul '24 - 16:50 »
2024-07-21: xmp-openmpt version 0.7.9 released!

 *  [**Sec**] Potential division by 0 when seeking in the module with
    `seek.sync_samples` enabled (r21167).

 *  [**Change**] The work-around for
    <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049> has been changed from
    forcing `-O1` on GCC 14 to setting `-fno-ipa-ra` on all GCC versions on
    non-ELF platforms. We are still not 100% sure if this work-around is
    sufficient in all circumstances. If you are using a non-ELF platform, it is
    strongly recommended to update GCC to versions 12.5.0, 13.4.0, 14.2.0, or
    15.1.0 as soon as they are released, or to apply the patch from the linked
    GCC issues.

 *  MOD: Allow sample swapping to work when swapping from a non-looping, stopped
    sample back to a looping sample (fixes MOD.energy).
 *  DBM: Import second sustain point in case the first sustain point is not set,
    or if it has a lower index than the first.
 *  DBM: When several instruments referenced the same sample with different
    properties (volume, loop points, etc.), only one set of properties was
    imported (fixes DBM.Supernova).
 *  DBM: Prioritize effects more correctly when the same effect is encountered
    in both effect columns of a cell (fixes DBM.143_Gnoj).
 *  DBM: Don't import offset effects when there's a tone portmento next to them.
 *  DBM: A few IT-specific playback quirks are disabled for more accurate
    playback (e.g. in "Are You Flying With Me?" by Jazzcat).
 *  DIGI: Sample play direction was reset if adjacent channel contained a
    Note Cut note.
 *  AMF: When running out of sample slots, file reading became be misaligned
    because the sample name was not skipped.
 *  MED: Command 0F was not imported.
 *  MED: Upper frequency limits should be more accurate now.
 *  MED: Channel panning is now only applied in MMD2 files if the free pan flag
    is set.
 *  MED: Volume command resolution was incorrect for pre-MMD3 files.
 *  XM: oggmod does not support stereo samples but keeps the stereo flag when
    encoding such samples. Such samples are now imported as mono samples instead
    of not importing them at all.
 *  XM: For files saved with registered MadTracker 2 versions, do not put
    binary garbage (the user ID) in the tracker metadata field. It is replaced
    with "registered" instead.
 *  For some truncated files, the used tracker was not identified correctly.
 *  S3M: Identify files saved with early Impulse Tracker versions, Sound Club 2,
    Liquid Tracker, NESMusa, UNMO3, deMODifier, Kosmic To-S3M, and better tell
    old ModPlug Tracker versions apart.
 *  S3M: When skipping sample loading, some tracker identifications were not
    working as intended.
 *  IT: Identify files saved with itwriter.
 *  DTM: Identify files saved with Digital Tracker 2.3.

 *  xmp-openmpt: If there is only one subsong, set the song title to the
    "global" song title instead of the name of that subsong.
 *  xmp-openmpt: Sample and instrument names were not sanitized, sometimes
    showing on multiple rows.

See https://lib.openmpt.org/libopenmpt/2024/07/21/security-updates-0.7.9-0.6.18-0.5.32-0.4.44/

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 #284 on: 21 Jul '24 - 17:11 »
OctaMED Soundstudio V1.03c seems to not open this MMD2 in Mix mode by default (unless "Use Mixing (MMD)" in Miscellaneous Options is switched on) but stereo separation slider in plugin has no effect.
Again, the stereo separation has no effect because it it is a user setting for the widening or narrowing the final mix. That is, if a channel panning table with all-center panning was loaded, stereo separation cannot undo that. I'm still not sure which Amiga versions of OctaMED or MED Soundstudio actually support this panning table, because in MED Soundstudio I cannot find it, despite version 1.03c being newer than the document that describes the free panning table. So for the time being I'll have to assume that it should only be used if free panning is enabled and hardware mixing is disabled. Let's see what breaks next...

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #285 on: 24 Jul '24 - 10:03 »
MED.(Liberation)intro
 ‣ Instrument 1 e.g. in the first channel of the first order should not be muted after several rows
 ‣ Plugin reports duration of 5:26 but stops playing at 7:18

Plugin reports duration of 1:55 for the second subsong but stops playing at 2:56

Plugin reports duration of 3:51 but OctaMED Soundstudio stops playing at 4:05 (see e.g. 3rd order from row 67)

BTW, could the plugin display the current order number on the Pattern Display or in main window like XMPlay does?

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #286 on: 25 Jul '24 - 20:17 »
Hybrid instrument loops should now be imported correctly, and length calculation inconsistencies in MED (and also MDL) should be gone too.

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #287 on: 26 Jul '24 - 19:01 »
Song length when different subsongs have different initial speed or tempo is fixed (all formats), as well as MED command 09 with parameters > 20 and <= 32.

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #288 on: 4 Aug '24 - 21:03 »
ok.sfx
⁍ channel 4 at 3rd position isn't played accurately

daylight.sfx ⁍ clicks on channel 3 at first position
freeflight.sfx ⁍ clicks on channel 4 at first position
freedom91.sfx ⁍ clicks on channel 2 at second position

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #289 on: 5 Aug '24 - 23:01 »
SFX arpeggios are now emulated more accurately, and oneshot samples in SFX files are now shortened if the sample header indicates a smaller size than the actual sample data size.

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #290 on: 9 Aug '24 - 10:47 »
MED.Untitled6
‣ vibrato doesn't sound quite accurate eg. on two last channels at 4th position

MED.Aria
‣ plugin doesn't play subsongs 6-19, 21

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #291 on: 9 Aug '24 - 19:11 »
Both problems should be fixed.

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #292 on: 11 Aug '24 - 21:55 »
· It seems that the tempo at the beginning of the 3rd position in this MED is set incorrectly.

· Portamento up reaches too high on channel 7, 8 at first order in this 669.

· The title of this 669 isn't displayed in full.

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #293 on: 8 Sep '24 - 13:16 »
The first two issues are now fixed, the third one will require a bit more work for a proper fix and an issue was created to track that: https://bugs.openmpt.org/view.php?id=1813

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #294 on: 9 Sep '24 - 11:33 »
· It seems that the tempo at the beginning of the 3rd position in this MED is set incorrectly.
... fixed
• Plugin reports duration of 3:53 but but the playback stops at 1:23.

on our way.669
  Sample 5 ← channel 3, 4 ← order 0 is played too high.

• Plugin plays this OKT too slowly at the beginning.

bugfixed (the song).ptm
  Starting at 2:26, PolyPlayer plays bass deeper.

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #295 on: 9 Sep '24 - 18:38 »
bugfixed (the song).ptm
  Starting at 2:26, PolyPlayer plays bass deeper.
It sounds identical to me, compared to both PolyPlayer and PolyTracker? Can you provide a recording of what you hear in xmp-openmpt and what you hear in PolyPlayer?

Edit: I think I figured it out. There's a bug in PT's panning command where extreme panning positions cause the note to played at higher volume.

Quote
Plugin reports duration of 3:53 but but the playback stops at 1:23.
The correct length is now reported.

Quote
• on our way.669
  Sample 5 ← channel 3, 4 ← order 0 is played too high.
Effects were quite messed up after the last 669 fix, now they should be correct again.

Quote
• Plugin plays this OKT too slowly at the beginning.
This should also play as intended now.
« Last Edit: 9 Sep '24 - 22:19 by saga »

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #296 on: 10 Sep '24 - 11:02 »
bugfixed (the song).ptm
  Starting at 2:26, PolyPlayer plays bass deeper.
After recent fixes, changing position with slider doesn't work accurately (eg.
bass before starting at 2:26 starts at ~2:54 after changing position with slider).

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #297 on: 10 Sep '24 - 13:30 »
This broke due to the MED song length calculation fix, and should now hopefully work again.

guest

  • Guest
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #298 on: 11 Sep '24 - 13:29 »
So-So-Mahhn-REmix.med
Sample 13 ← 3rd channel ← second order doesn't seem to be played accurately.

saga

  • Posts: 2787
Re: xmp-openmpt: An XMPlay input plugin based on OpenMPT
« Reply #299 on: 11 Sep '24 - 17:30 »
It seems like MED Soundstudio for Amiga and Windows disagree on how to play that sample. OpenMPT plays it the way the Windows version does.

Edit: And without knowing which of the two programs was used, the Windows version definitely sounds more like it was intended to sound like that.
« Last Edit: 12 Sep '24 - 10:56 by saga »