'[b]Mod08k'[/b] is one of several variants of the '[[s3xmodit%20(format)[S3XMODIT] module format that severely restrict the size of your module - in this case, '[b]8 kilobytes'[/b] (8192 bytes). Until the addition of mod04k in late 2019, this was the smallest (and thus most challenging) one!
Unlike S3XMODIT, this format provides '[[Chipist%20(class)[Chipist] points instead of '[[Mixist%20(class)[Mixist] (more info on classes '[[BotBr%20Classes[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 8KB or less (8192 bytes).
* The accepted file formats are the same as in the normal S3XMODIT category: '[b].s3m'[/b], '[b].xm'[/b], '[b].mod'[/b] and '[b].it'[/b].
* '[b]DO NOT'[/b] use FM instruments in .s3m format; this is a sample-based format only.
* '[b]For OpenMPT users:'[/b] Usage of DirectX DSP effect plugins (or any other VST) is not allowed, as this is a specific feature of the software that will not be reflected in any other program that opens the module. See the '[[openmpt (format)[OpenMPT format] if you want those.
'[#[Module optimiziation]
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!
'[t[b3]Some basic tips and tools:'[/t]
* 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[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 in the smallest formats, and potentially way more in the larger ones thanks to its sample compression. Run your module through here at the very end!
* Similarly, if you're using .xm, '[[BoobieSqueezer[BoobieSqueezer] (yes, really) is a tool that will optimize your module data even further while remaining completely playable and format-accurate.
* 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.
* '[b]What's the most efficient module type?'[/b]' Generally it's '[b].it'[/b], which handles empty space the best of the bunch. '[b].xm'[/b] is viable too 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.
'[t[b3]Space-saving tips:'[/t]
'[t[b1]Samples'[/t]
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. Note that Munch.py (for .it) applies valuable space-saving compression here, which may turn out to be a huge amount in the larger mod*k variants. But that doesn't mean you shouldn't be efficient, and you may need to do some trimming to make space without editing your patterns.
'[t[b1]Downsampling'[/t]
You may be able to comfortably '[b]downsample your sounds'[/b], though they will sound flatter and flatter (losing high frequency content) each time.
In OpenMPT, use '[b]"Resample"'[/b] on the sample screen--the sixth icon from the left in the big row of buttons.
Try it and see how small you can get them before the resulting sound becomes unacceptable to you. The default "downsample" option halves the size, but you can also input your own value to downsize in whatever proportion you desire. Compare with the "Freq. (Hz)" value listed on the lower left of the sample screen. If the value is 22000, choosing "21000" for your resample value will make it only slightly smaller, for example, whereas 11000 would halve it.
'[t[b1]Speed'[/t]
Using '[b]lower speed settings'[/b] (i.e. high number of ticks per row) will help you save space overall because there will be less empty space inbetween your notes. Consider using the '[b]slowest speed you can'[/b] while still being able to contain the notes you want, so as to have few (or no) blank rows.
The speed can be briefly raised for a flourish of fast notes and then lowered again (with '[t[mono]Axx'[/t] (.it)/'[t[mono]Fxx'[/t] (.xm)).
Also, the '[t[mono]SDx'[/t] (Note Delay) command can be used for intermittent offsetting from the slow-speed grid.
'[t[b1]Pattern Delays'[/t]
Blank rows can be trimmed by using the '[b]Pattern Delay command'[/b], '[t[mono]SEx'[/t] (.it) or '[t[mono]EEx'[/t] (.xm) in the row before the blank rows would happen. This extends the length of the row by holding in place '[t[mono]x'[/t] times, where '[t[mono]x'[/t] is the length of one row.
For example, '[t[mono]SE1'[/t] at speed 6 would cause that row to be held for 12 ticks instead.
If there's nothing in between a bunch of rows, consider using this command and moving everything else up to fill the space!
Another way to do this is by changing the speed - for instance, setting the speed to 16 in the middle of music that's speed 4 in order to hold for four rows' worth of time, then switching back to 4. Doing it this way may consume marginally more space, though.
Notably, there is a strange interaction between Pattern Delays and the Note Delay command ('[t[mono]SDx'[/t] (.it)/'[t[mono]EDx'[/t] (.xm)); if used on a row containing a Pattern Delay, the delayed note will repeat with each iteration of the Pattern Delay. At times this may be unwanted, but it can also potentially be used to your advantage.
'[t[b1]"Continue" Commands'[/t]
'[b]Do not use "continue" commands'[/b] (e.g. '[t[mono]H00'[/t], '[t[mono]D00'[/t], etc) in .it. It is more efficient to write '[t[mono]H44 H44 H44'[/t] than '[t[mono]H44 H00 H00'[/t].
Munch.py should change this for you automatically, but it is good practice to get used to it.
'[t[b1]Repeated Commands Are Compressed'[/t]
Reuse of previous commands in .it saves space if they are used in succession--for '[o]all'[/o] columns.
For example, '[t[mono]v56 v56 v56 v56'[/t] will take up less space than '[t[mono]v56 v12 v56 v12'[/t].
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.
Other effects will also be compressed if used without something different separating them, as detailed in the next tip.
'[t[b1]Volume Column vs. Effect Column'[/t]
In general, for .it, '[b]volume column commands'[/b] take up 3 bytes of space apiece, while '[b]effect column commands'[/b] take up 4 bytes of space. Thus it is likely more efficient to put volume slide commands in the volume column ('[t[mono]Dx'[/t]/'[t[mono]Cx'[/t]/'[t[mono]Bx'[/t]/'[t[mono]Ax'[/t]).
For .xm, instead it's 1 byte and 2 bytes, respectively!
As mentioned above, compression of consecutive effects occurs in .it format - even if there are blank rows inbetween their uses.
For compression in the volume column, the first repeated effect is reduced from 3 bytes to 2, and all subsequent repeated effects get reduced to 1 byte!
For the effects column, reuse of the same type of effect (e.g. two H commands) consumes 1 fewer byte, and likewise for reuse of the same effect value (e.g. A4), regardless of the effect itself.
This means that with subsequent uses of the same effect, for example '[t[mono]E02 E02 E02'[/t], all effects after the first consume 2 bytes instead of 4. Different values for E would change this to 3 bytes, as would different effects all using value 02.
Note that if using '[t[mono]Hx'[/t] for vibrato in the volume colum, it must be "initialized" with an '[t[mono]Hxy'[/t] effect command prior, to set the desired speed.
'[t[b1]Note Cuts'[/t]
Note Cuts '[t[mono]^^'[/t] may take up more space than using a '[t[mono]v00'[/t] command, although this may depend somewhat on what effects you might be using in the volume column, and may be undesirable if using a New Note Action in Instrument mode other than the default Cut. If you need to do some trimming though, try swapping Note Cuts out for '[t[mono]v00'[/t] commands.
'[t[b1]The "Unmute Trick"'[/t]
It is possible to save pattern space in .it by using the '[t[mono]Mxx'[/t] (Channel Volume) command to mute and unmute channels of your choice.
For example, if you wrote a pattern that you wanted to copy and add something to, you could have the Channel Volume at 0 for the first pass, then set it to a new nonzero value with '[t[mono]Mxx'[/t] for the second pass - all contained within one pattern.
('[l[http://battleofthebits.com/arena/Entry/gunjo/20779/[Example module])
'[t[mono]M40'[/t] is the maximum (which is 64 in hex).
A channel can start out muted by setting its volume to 0 in the General tab.
'[t[b1]Pattern Loops'[/t]
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 '[b]Pattern Loop command'[/b] ('[t[mono]SBx'[/t] in .it, '[t[mono]E6x'[/t] in .xm).
Placing an '[t[mono]SB0'[/t] command at row 1 and an '[t[mono]SB2'[/t] command at row 4 will cause 1-4 to loop twice before proceeding. This is potentially a huge space-saver. In this example your pattern's length would be halved, from 16 to 8 rows.
They are also another way to potentially take advantage of the "unmute trick" in .it for adding new sounds on a second loop through something. Try placing an '[t[mono]Mxx'[/t] command alongside the second '[t[mono]SBx'[/t], or even after it for additional unique loop passthroughs!
Pattern loops can also be nested! Try experimenting with loops inside of loops.
Notably for .it, the end of a Pattern Loop can't occur on a row that contains a Pattern Delay '[t[mono]SEx'[/t] command. The loop will simply not occur. This works fine in .xm however.
'[t[b1]Instruments'[/t]
Instruments in .it take up almost 400 bytes apiece, so avoid using Instrument mode unless you plan to take advantage of the features like New Note Actions (NNAs), random volume/panning sliders, sample maps and/or the various envelopes.
If you are just using ADSR volume envelopes, they are probably best represented with '[t[mono]Dx'[/t]/'[t[mono]Cx'[/t]/'[t[mono]Bx'[/t]/'[t[mono]Ax'[/t] (vol column) or '[t[mono]Dxy'[/t] (effect column) commands.
You may be able to get away with this in the larger mod*k variants but be aware of the space they consume.
Also, for maximum efficiency, make sure the order of your samples and instruments matches! Occasionally Munch.py has issues if they are out of order, too. You can reorder them in OpenMPT's "Tree" view sidebar.
'[t[b1]Merging Patterns'[/t]
Merge/combine patterns that are only used once (or only ever used adjacently), as they may take up a few bytes more of space when separated.
Also, pattern separators '[t[mono]+++'[/t] in .it take up a byte apiece (as well as any other addition to the pattern order), making them technically trimmable chaff.
'[t[b1]Auto-Vibrato'[/t]
Rather than using vibrato commands, the '[b]"Auto-Vibrato" setting'[/b] on the sample screen can be used to automatically apply vibrato at a chosen rate, depth and "sweep" (which sets the length of time until vibrato starts happening).
This can be set for every sample, without even needing Instrument mode!
In .it format, rate can be 0-63 with 63 being the fastest; depth can be 0-31 with 31 being the widest; and sweep can be 0-255 with 255 making it occur immediately.
For .xm it's slightly different: rate is still 0-63 with 63 being the fastest; depth can only be 0-15 with 15 being the widest; and sweep can be 0-255 but instead the value is exactly the number of ticks until vibrato triggers, so 0 is immediately.
'[t[b1]What '[o]doesn't'[/o] take up space?'[/t]
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.
Similarly, repeated instrument column values don't take up space either, so trimming them is not important.
'[t[b1]Text Fields'[/t]
The song Name field in the General tab takes up no space, so feel free to indicate preferred interpolation settings here.
The Artist field, however, '[o]does'[/o] take up additional space, so Munch.py will trim it away.
The name fields for samples and instruments do not take up additional space.
However, the name fields for Channels (set in the General tab) do take up space, so avoid using those.
'[#[Playback for voting]
Two recommended tools for playback are:
* '[[MODPlug%20Tracker[OpenModPlugTracker (OpenMPT)]
* '[[Schism%20Tracker[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 '[b]Milky Tracker'[/b]'s *.it playback '[b]'[u]'[t[b1]is not'[/b]'[/u]'[/t] 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 '[[MODPlug%20Tracker[OpenModPlugTracker (OpenMPT)], which adequately handles all S3XMODIT formats. Remember that DirectX effects plugins (or any other VST) are not allowed here though.
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:
* '[[Scream%20Tracker%203[*.s3m '[t[t tab]'[t[t tab] (Scream Tracker 3)]
* '[[FastTracker%20II[*.xm '[t[t tab]'[t[t tab]'[t[t tab] (Fast Tracker II)]
* '[[ProTracker[*.mod '[t[t tab]'[t[t tab] (Amiga ProTracker)]
* '[[Impulse+Tracker[*.it '[t[t tab]'[t[t tab]'[t[t tab]'[t[t tab]'[t[t tab] (Impulse Tracker)]
'[#[See also]
Here are the other mod*k formats:
* '[[mod04k (format)]
* '[[mod12k (format)]
* '[[mod16k (format)]
* '[[mod24k (format)]
* '[[mod32k (format)]
* '[[mod48k (format)]
* '[[mod64k (format)]
Related formats:
* '[[s3xmodit%20(format)[S3XMODIT '[t[t tab]'[t[t tab] (*.s3m, *.xm, *.mod, *.it)]
* '[[amigamod%20(format)[Amigamod '[t[t tab]'[t[t tab] (*.mod)]
* '[[mptm+%28format%29[ModPlugTracker Module '[t[t tab]'[t[t tab] (*.mptm)]
Related articles:
* '[[IT Module Optimisation] (some more technical stuff than what's written here)
