Hi all, I'm bringing this up following some discussions relating to the current ongoing tournament:

Small module formats currently require submissions to be in the classic .s3xmodit file types, excluding OpenMPT's .mptm. This is presumably done to keep in line with the Classic DOS modules format. In the case of the Classic DOS format, it makes sense in keeping with the "classic" intent of it that it excludes .mptm, which is essentially an updated .it. However, in the case of small module formats 4K-64K, the primary focus of these is around file size and module efficiency. There is also an mptm specific format, which focuses on this file type's exclusive features. My question is, can we also consider allowing .mptm files into the small module formats? Any concerns or reasons to avoid besides the fact that there is already a dedicated mptm format?

Some pros and cons:
-Allowing this file type in small module battles would allow us to use it a bit more often, since currently it only shows up in the MPTM format, and may open some new ground for exploring what can be done with it.
-all of these file types can be done in OpenMPT, for those who use it
-on the flip side, mptm can only be opened in OpenMPT, which is Windows exclusive and could therefore be potentially limiting that way. However, OpenMPT should run through Wine 1.8+. Anybody Linux folks have experience with using it this way?
-all the same smallmod requirements would exist -- samples only, no OPL instruments, etc.
-the mptm file type doesn't necessarily have a clear advantage over .s3xmodit files in terms of efficiency for small modules, but it does have some additional features. From OpenMPT's wiki, these are some of the other things exclusive to mptm:

Effect Commands


S7D: Force Pitch Envelope


S7E: Force Filter Envelope


:xy: Note Delay + Cut


#xx: Paremter Extension


+xx: Fine note tuning


*xx: Smooth fine note tuning (slides)


o0x: (volume cmd): Sample cue / offset





Instrument Settings


-Ramping/resampling settings per instrument


-Filter mode (default/force lowpass/force highpass)


-Cutoff Swing


-Resonance Swing


-Alternate pitch/filter envelope using S7D/S7E commands


-Custom tunings (edo settings? This stuff's above my head)

What are your thoughts? Any concerns? Any history here that would add extra context?

Thanks!

i'm personally against including .mptm in the tinymod formats, mainly because of the [DirectX] plugins. (but, as i will type a bunch about, it might be okay without the plugins, just potentially confusing!)

imo the plugins completely change the game, even though yes there's still plenty of cool stuff you can do with just .it New Note Actions and all sorts of fun tricks to fake DSP. having access to actual reverb, delay, distortion, EQ, chorusing and compression though really threatens to blow the other formats out of the water. even if those plugins are a little dinky.

doing a little bit of testing, it looks like adding 1 plugin contributes ~0.2kb to a module, which is imo pretty negligible. it seems that Parameter Control events (PC/PCs) take up about as much space as a normal effect once utilized, but adding the first one costs ~0.25kb. consider that adding, say, an echo channel with detuning effects would likely be more costly on space than just adding a delay or reverb plugin... not to mention the extra controls you get over the sound in the plugin(s).

if we were to add a special restriction to prohibit plugin use, i think i'd be okay with it in theory. but that would also be confusing since they are allowed in the .mptm BotB format. also, even though most people do use OpenMPT for s3xmodit formats, it adds a certain accessibility restriction to the tinymods, notably for voting in XHBs.

most of the other .mptm features are kind of niche - some cool ones for sure, like \xx filter (or macro) sweeps and :xy note delay+cut, high pass filter, random filter value sliders, and of course the alternate tunings feature of instruments which i'd be very, very excited about tbh (quick testing there seems to show ~0.1-0.4kb per alternate tuning, size relative to how many notes are contained in the scale). also, .mptm offers better compression for stereo samples, so that makes those slightly more viable. all these things rock and are not game-breaking.

it's also worth mentioning that "mpt hacks" have sorta been soft-allowed in my time here at least - this includes stuff like S9E/S9F (play sample forward/play sample backward) and \xx filter sweeps. (it's kinda just your loss if you include these and the voter is not using mpt, right??) this might be a point in .mptm's favor, as it gives those effects a clear home. it'd really be best to relegate them to their own format.

size-wise it's pretty darn comparable to .it as near as i can tell. re-saving an .it module as .mptm very slightly increases the filesize but it's also fairly negligible at less than 0.1kb. .mptm also can't be munched* so it interestingly loses a bit of efficiency in that regard.
(* well technically it can, but all the .mptm specific stuff will just get removed. someone could make a modified munch.py perhaps!)

these are my thoughts! it's not out of the question without plugins but i really don't like the idea of it with plugins.

I was also thinking in terms of not allowing plugins, that seems a given to me almost on par with not allowing OPL instruments, but now that you mention it, it's a good point that this would be a bit confusing to disallow in smallmods but allow in OpenMPT format

to be fair, OPL instruments are allowed in .mptm BotB format too, but not in the s3xmodits. i guess it's no more or less confusing than that. .mptm is unrestricted, the rest are

Small module compos and the s3xmodit formats have a deep-seated tradition within the demoscene going back decades. .mptm does not. Adding it as a tinymod option is a misguided notion. It's like asking a vintage car competition if they could include a late-model Toyota Corolla. There's nothing particularly impressive or interesting about seeing a 2005 Corolla going 55 mph on a closed circuit or towing a 1,000 pound trailer, even though (and also precisely because) it's easier to do those tricks in a Corolla than a Model T.

It's not even strictly because .mptm is "better" than the four s3xmodit formats - it's basically consensus that .it is "better" than the other three (as well it should be, since it's the most recent). But .it is classic, .mptm isn't, and probably never will be. King Gizzard is a very successful rock group, but they're not going to ever be considered "classic rock" alongside Zeppelin, the Who, and the Rolling Stones. Doesn't make them necessarily better or worse - it's just a different category.

I also think classic DOS module (and by extension the size limited module formats) should not include .mptm, for the same reasons Lint_Huffer mentioned - I would consider OpenMPT/.mptm modern compared to the current set of module formats in the classic DOS module set. As a point of reference, most demoparty compos seem to not include .mptm as an allowed format in their tracked music compo rules (@party, Assembly, and Revision to name a few).