sezero/mikmod

[Feature Request] - New module formats

neumatho opened this issue · 4 comments

neumatho commented

It seems that libxmp can load more different module formats than MikMod. It would be nice, if those can be adapted to MikMod.

I don't mind to give it a try at some point, if it is ok to take the code from libxmp (more or less) and make a MikMod loader from them.

AliceLR commented

My take on this: it's a fairly absurd amount of work to make sure some module formats are supported correctly (see: #18 #23 #25 #37) and MikMod has deficiencies in the formats it already does support. This isn't a problem unique to MikMod, either: libxmp's FAR support was barely better off than MikMod's before I started my patch, its MED/OctaMED effects edge cases are worse than MikMod, and I've had to put quite a bit of work into Impulse Tracker and Digital Symphony modules. More formats would be nice, but I think continuing to fix the formats MikMod already does support would probably be better.

Formats that should be mostly fine:

  • MOD, MOD (15 instrument), S3M, XM, DSMI AMF, ASYLUM, GDM, STM, UMX, UNI.

Formats with well known deficiencies:

  • IT: no sustain loops, no stereo samples, probably a bunch of other issues no one noticed yet.
  • FAR: :)
  • GT2: the loader is deadcode.
  • MED: I recommend staying as far away from this loader as possible. This is an absurd format and I've been slowly chipping away at issues it has. There are hundreds of example modules to verify for any given issue, and various versions of the original trackers need to be run in an Amiga emulator for this verification. No IFF#OCT instruments, no synth/hybrid instruments, no extsample instruments, no hold/decay, no multiple songs, no command pages, no MMD2/3, and a handful of other issues.

Formats in desperate need of a deep dive to find bugs. Said bugs are almost guaranteed to exist:

  • 669 (Composer 669 and Unis 669) uses some persistent effects like FAR and ULT. Unis 669 also has a "speed 0" that nothing currently supports. Composer 669 uses the SB16 and can be run in DOSBox with minor keyboard bugs. Unis 669 uses the GUS and runs in DOSBox but doesn't have working sound.
  • DSM (DSIK RIFF format)
  • IMF (IMAGO Orpheus)
  • MTM (MultiTracker)
  • OKT (Oktalyzer (Amiga))
  • STX (STMIK)
  • ULT (Ultra Tracker)
sagamusix commented

Fully agree with Alice here. mikmod's support of some of the most popular formats is abysmal, and before anything else this must be fixed. It doesn't make sense to offer more formats while so many files are played incorrectly already, and it really doesn't make sense to have so many different module playback libraries available that are all mediocre at best at playing the most popular formats. Otherwise the outcome of this request is simply "libxmp with mikmod library interface, but worse". Really, I don't think adding any new features to mikmod makes sense at this point without a serious rewrite because the library itself is already stuck in the past - not being threadsafe by using global variables everywhere being one of the biggest issues of the current library design.

AliceLR commented

I don't think adding any new features to mikmod makes sense at this point without a serious rewrite because the library itself is already stuck in the past - not being threadsafe by using global variables everywhere being one of the biggest issues of the current library design.

Right. What MikMod really needs right now pretty much is a new major version to address the following issues:

  • Win32 API types bitrot. Preferable solution: stdint.h (will Autoconf/./configure define replacements if they aren't found? I know it loves to waste time checking for each individual type from that header...).
  • Recursive Makefiles bitrot. They've been known to be terrible since the '90s and Automake doesn't actually need them to work. (OK, this doesn't actually need a major version, but I am tired of how slow it is to build this library in MSYS2.)
  • Issues caused by nearly all types being in the public API or internal globals.
    • Non-reentrant bitrot. This is kind of a huge problem for MegaZeux because with the other players it allows playing multiple modules simultaneously as sound effects. There are games that actually rely on that! Usually this replayer only gets enabled for embedded platforms though, which is why I don't complain about it more.
    • No global player data structure (see the hacks required for FAR).
    • No sustain loop fields in the sample struct (IT). This is false, I was thinking of libxmp. They exist in MikMod but they're unused.
    • Need void * handles in module, instruments for private extensible data for certain formats (MED/OctaMED synths and hold/decay!).
    • Extend quirk flags field to uint32_t, add a second overflow quirk flags field just in case.
    • Private context handle for any other globals that previous doesn't cover.

I don't know that there's a way to make the drivers reentrant but I doubt it'd be necessary, if you're doing that you pretty much need to bring your own software mixer anyway. I'm not familiar enough but going off everything else in this library, they could probably use some additional safety checks after the other stuff is done.

sezero commented

Major overhaul, yes - and I like the idea :)