Tracker Module file made by using samples!
files no larger than 24,576 bytes
- Restrictions on submit
- Module optimiziation
- Playback for voting
- Tools for creation
- See also
is one of several variants of the S3XMODIT
module format that severely restrict the size of your module - in this case, 24 kilobytes
(24576 bytes). Compared to the smaller variants, this format offers a healthy amount of space for samples.
Unlike S3XMODIT, this format provides Chipist
points instead of Mixist
(more info on classes here
). In fact, all of the so-called "mod*k/modXk/limited-k" module formats except the largest one, mod64k, grant Chipist points! Reasons for this include the necessity of very small, shortlooped samples & the general philosophy of needing to say more with less.
Check out the "See also" section below for links to the other mod*k variants and formats closely related to them.
Restrictions on submit
* Your submission should be 24KB or less (24576 bytes).
* The accepted file formats are the same as in the normal S3XMODIT category: .s3m
* DO NOT
use FM instruments in .s3m format; this is a sample-based format only.
The meat and potatoes of all the mod*k formats is optimizing your module to the best of your ability! Particularly in the smaller variants, it is VERY easy to fill up this amount of space in no time. Luckily, there are many practices you can follow to squeeze in as much info as possible... which is where the fun starts!
Some basic tips and tools:
* In OpenMPT's Edit menu, you will find options for "Cleanup" and "Automatic Sample Trimmer". Both of these tools can save you space and are best run near the end of your work.
* If you're using .it, Munch.py
is a tool that will optimize your module data even further; results may vary, but you can expect to save 0.5-1.5KB overall. Run your module through here at the very end!
* Similarly, if you're using .xm, BoobieSqueezer
(yes, really) is a tool that will optimize your module data even further.
* What's the most efficient module type?
Generally it's .it
, which handles empty space the best of the bunch. .xm
is viable if you prefer, but .xm is best used if the song data is quite dense; otherwise your song may take up more space than if it were .it. The least viable option is .mod. Tread carefully.
* Samples take up a lot of space. Use small, mono, 8-bit sample data. Ensure there is no extra data after the loop; it is useless space. Likewise for any silence at the start of your sample.
* You may be able to comfortably downsample your sounds too, though they will sound flatter and flatter (losing high frequency content) each time. (In OpenMPT, use "Resample" on the sample screen.) Try it and see how small you can get them before the resulting sound becomes unacceptable to you.
* Using lower speed settings (i.e. high number of ticks per row) will help you save space overall because there will be less empty space inbetween your notes.
* In OpenMPT, using "Compatibility Export" from the File menu may save a small amount of space; it's shaving away a few newer features to be better compatible with the original DOS trackers.
* Big .it tip:
Reuse of previous commands saves space if used in succession--for all columns. For example, "v56 v56 v56 v56" will take up less space than "v56 v12 v56 v12". This means that it's best to stick with constant volumes where possible, and if you are alternating between volumes, separating them into their own channels is a better use of space.
* Do not
use "continue" commands (e.g. H00, D00, etc) in .it either. It is more efficient to write "H44 H44 H44" than "H44 H00 H00".
* In smaller formats, don't use Instrument mode
- each Instrument takes up almost half a kilobyte! You may be able to get away with this in the larger variants but be aware of the space they consume.
* Extra channels do not actually take up space in .it - unless they're full, of course. A 24-channel .it file will be the same size as 1-channel if blank.
* Spicy .it tip
: It is possible to save pattern space in .it by using the Mxx (Channel Volume) command to mute and unmute channels of your choice. For example, if you wrote a pattern you wanted to copy and add something to, you could have the Channel Volume at 0 for the first pass, then set to a new value with Mxx for the second pass - all contained within one pattern. (Example
* If there are smaller repeating chunks of pattern data (for example, you wrote a 16-row pattern where the stuff in 1-4, 5-8, and 9-12 is identical), you can save space by using the Pattern Loop command (SBx in .it, E6x in .xm). Placing an "SB0" command at row 1 and an "SB2" command at row 4 will cause 1-4 to loop twice before proceeding. This is potentially a huge space-saver.
Playback for voting
Two recommended tools for playback are:
* OpenModPlugTracker (OpenMPT)
* Schism Tracker
Generally speaking, all tools / editors that allow for playback of one of the specific formats will do. Software which use the modern and very accurate 'libopenmpt' library should suffice as well.
However, it is known that Milky Tracker
's *.it playback is not
accurate, as it's not fully compatible with the *.it file format (it does not correctly emulate NNAs, instruments, channel commands, and many more aspects of the format and instead tries to convert the *.it to an *.xm).
Tools for creation
As with playback, the most popular tool for the job is currently OpenModPlugTracker (OpenMPT)
, which adequately handles all S3XMODIT formats.
You can use the original tracker tool of a given format to make your entry too, though all of these are written for the MS-DOS platform and require the user to use either a real computer that runs MS-DOS or use a virtual machine (e.g. DOS-BOX) that can emulate a computer running MS-DOS:
* *.s3m (Scream Tracker 3)
* *.xm (Fast Tracker II)
* *.mod (Amiga ProTracker)
* *.it (Impulse Tracker)
Here are the other mod*k formats:
* mod04k (format)
* mod08k (format)
* mod12k (format)
* mod16k (format)
* mod32k (format)
* mod48k (format)
* mod64k (format)
* S3XMODIT (*.s3m, *.xm, *.mod, *.it)
* Amigamod (*.mod)
* ModPlugTracker Module (*.mptm)
* IT Module Optimisation
(some more technical stuff than what's written here)