Development: Test Cases/MOD

This test suite is a collection of MOD modules that were created while discovering playback bugs in OpenMPT. It is meant to be an easy way to check for regressions when code is changed, or to verify your own player’s routines if you are concerned about playback compatibility. The tests are designed in a way so that it is easy to figure out if your player is working correctly. In most test cases, your own player’s output can be heard on the left channel, while ProTracker’s output is heard on the right channel. This way, it is easy to find out whether everything works as intended or if there are any discrepancies without having to read any long test descriptions. When it is impossible to do such a cross-verification, a more detailed description of the test can usually be found in the sample, instrument or comment text.

Some test cases mention that they should stay quiet when played correctly. This does not take different ramping algorithms into account (so there might me a small “pop” at the start of samples or when changing the volume), and it is generally expected that the test cases are rendered at a mix rate of 44100 Hz, as otherwise different calculations of channel playback speed and interpolation settings may cause small but noticable differences in playback.

Bit-exact output is not the goal of this test suite, correct playback is, so slight deviations from ProTracker’s output (e.g. different resampling algorithms, pop reduction, etc.) are acceptable. Some tests will only sound correct on the first run. Unless stated otherwise, it is not important that the test output sounds identical when looping the module.

Most test cases are documented (more or less) in OpenMPT’s source code with a reference to the filename of the test case. I am sorry that many tests do not have proper descriptions − I have started this documentation years after I have fixed some of these issues and can thus not remember all the details anymore. If you are stuck with one of the tests, you may have a look at specific source code revisions that are provided with most tests to see what was changed in the code to make it work correctly.

Last but not least, please keep in mind that some descriptions might be wrong or too general. Sometimes, the description might be correct in the given test case, but changing the test case slightly might completely invalidate the description of how an effect is supposed to work, for example. If you know better than me, please correct the texts, and please ask me if you need more information one of the test cases. The documentation is not always optimal because the test cases have been written long before I have created this site.

AmigaLimitsFinetune.mod

Current status: OpenMPT passes this test since revision 1555.
Download: AmigaLimitsFinetune.mod
Description: ProTracker does not always clamp samples to the exact same range of periods — it rather depends on the actual finetune value of the sample. In contrast to that, Scream Tracker 3 always clamps periods to the same range in its Amiga mode. This test file should stay completely in tune at all times.

ArpWraparound.mod

Current status: OpenMPT passes this test since revision 1537 + 6738.
Download: ArpWraparound.mod
Description: If an arpeggio parameter exceeds the Amiga frequency range, ProTracker wraps it around. In fact, the first note that is too high (which would be C-7 in OpenMPT or C-4 in ProTracker) will play at a period of 0 (so just a static DC offset), C#7 / C#4 becomes C-4 / C-1, and so on.

DelayBreak.mod

Current status: OpenMPT passes this test since revision 2108.
Download: DelayBreak.mod
Description: If there is a row delay (EEx) on the same row as a pattern break (Dxx), the target row of that jump is not played. Instead, the next row is played.

finetune.mod

Current status: OpenMPT currently fails this test.
Download: finetune.mod
Description: ProTracker’s E5x finetune handling is a bit weird. It is also evaluated if there is no note next to the command, and the command is also affected by 3xx portamentos.

InstrDelay.mod

Current status: OpenMPT passes this test since revision 4212 + 8653 + 8674.
Download: InstrDelay.mod
Description: ProTracker always loads the new instrument settings (volume, finetune and sample pointer) on the first tick, even if there is a note delay. The new sample pointer is only used if the current sample is looped and its loop end is reached.

This quirk is implemented in ProTracker 1/2 mode.

InstrSwapRetrigger.mod

Current status: OpenMPT passes this test since revision 18955 + 18956.
Download: InstrSwapRetrigger.mod
Description: Instrument swapping should happen instantly (not at the end of the sample or end of sample loop like in PTInstrSwap.mod) when there is an E9x retrigger command next to a lone instrument number. As with regular sample swapping, the sample finetune is not updated. The left and right channel of this module should sound identical.

Note that the retrigger command can cause semi-random tiny delays with ProTracker on a real Amiga, so if there are small differences in phase between the left and right channel when playing this test in ProTracker but not in an external player, this is acceptable.

NoteDelay-NextRow.mod

Current status: OpenMPT passes this test since revision 8730.
Download: NoteDelay-NextRow.mod
Description: In ProTracker, a note delay greater than the current speed will cause the delayed note to be played on the first tick of the next row if there is no new note on the next row (even if that new note is also delayed). However, the note is note restarted but rather continues where a previous note left off playing (like an instant portamento).

PatLoop-Break.mod

Current status: OpenMPT passes this test since revision 5402.
Download: PatLoop-Break.mod
Description: Just as with XM and IT, a pattern break should not reset the pattern loop counter. You should hear two noise bursts, followed by the words “success”.

PatternDelaysRetrig.mod

Current status: OpenMPT passes this test since revision 9152.
Download: PatternDelaysRetrig.mod
Description: When there is a row delay (EEx), fine slides and note delays should be executed on every row repetition.

Note. OpenMPT does not apply ProTracker behaviour for this quirk if the MOD file contains more than 4 channels or notes outside of the Amiga frequency range. This is to avoid some potential issues with infinite pattern loops due to row delays that e.g. FastTracker 2 doesn't have (and thus FT2-made MODs would get stuck in an infinite loop where they should not).

PatternJump.mod

Current status: OpenMPT passes this test since revision 1321.
Download: PatternJump.mod
Description: A Bxx command should reset the effect of a Dxx command that is left of the Bxx command. You should hear a voice saying “success”.

PortaSmpChange.mod

Current status: OpenMPT passes this test since revision 3578.
Download: PortaSmpChange.mod
Description: The interpretation of this scenario highly differs between various replayers. If the sample number next to a portamento effect differs from the previous number, the new sample's default volume should be applied and

the old sample should be played until reaching its end or loop end (ProTracker 1/2). If the sample loops, the new sample should be activated after the loop ended.
the old sample should keep playing (various other players)

OpenMPT implements the second option in normal playback mode and the first option in ProTracker 1/2 mode.

PortaSwapPT.mod

Current status: OpenMPT passes this test since revision 6614 + 8665.
Download: PortaSwapPT.mod
Description: Related to PortaSmpChange.mod, this tests the portamento with sample swap behaviour for ProTracker-compatible MODs. Noteworthy tested behaviours:

When doing a sample swap without portamento, the new sample keeps using the old sample’s finetune.
When doing a sample swap with portamento, the new sample’s finetune is instantly applied, and the new sample is started as soon as the old sample’s loop is finished playing.

PortaTarget.mod

Current status: OpenMPT passes this test since revision 4726.
Download: PortaTarget.mod
Description: ProTracker’s portamento behaviour is somewhere between FT2 and IT:

A new note (with no portamento command next to it) does not reset the portamento target. That is, if a previous portamento has not finished yet, calling 3xx or 5xx after the new note will slide it towards the old target.
Once the portamento target period is reached, the target is reset. This means that if the period is modified by another slide (e.g. 1xx or 2xx), a following 3xx will not slide back to the original target.

PTInstrSwap.mod

Current status: OpenMPT passes this test since revision 4223.
Download: PTInstrSwap.mod
Description: When specifying an instrument number without a note, ProTracker 1/2 instantly applies the new instrument settings, but does not use the new sample until the end of the (loop of the) current sample is reached. In this example, sample 2 should be played at maximum volume as soon as instrument number 1 is encountered in the pattern, then sample 1 should be triggered somewhere around row 10 and then stop playing at around row 18.

PTInstrVolume.mod

Current status: OpenMPT passes this test since revision 12249.
Download: PTInstrVolume.mod
Description: This test verifies that a volume command set together with an instrument but no note will be kept once the note is triggered later.

ptoffset.mod

Current status: OpenMPT passes this test since revision 4018.
Download: ptoffset.mod
Description: ProTracker 1/2 has a slightly buggy offset implementation which adds the offset in two different places (according to tracker_notes.txt coming with libxmp: "once before playing this instrument (as is expected), and once again after this instrument has been played"). The left and right channel of this module should sound identical. OpenMPT emulates this behaviour correctly in ProTracker mode.

PTRetrigger.mod

Current status: OpenMPT passes this test since revision 14872.
Download: PTRetrigger.mod
Description: This tests the E9x implementation against the ProTracker implementation. Left and right channel should retrigger at the same intervals.

In summary, this is how the retrigger effect should work:

If current tick is 0 and there is a note, do not retrigger
If effect parameter is greater than 0, and the current tick modulo the parameter is 0, do retrigger

Note that the current tick counts upwards (starting at 0), and is reset on every repetition caused by the EEx (row delay) command.

PTSwapEmpty.mod

Current status: OpenMPT passes this test since revision 4950.
Download: PTSwapEmpty.mod
Description: ProTracker instrument swapping (see PTInstrSwap.mod test case) also works when swapping from an empty sample slot back to a normal slot: If the sample was already swapped, it is restarted immediately.

PTSwapNoLoop.mod

Current status: OpenMPT passes this test since revision 11843 + 11844.
Download: PTSwapNoLoop.mod
Description: ProTracker instrument swapping (see PTInstrSwap.mod test case) should also work when the "source" sample is not looped. However, when the "target" sample is not looped, sample playback should stop as with PTSwapEmpty.mod. Conceptually this can be explained because in this case, the sample loop goes from 0 to 2 in "oneshot" mode, i.e. it will loop a (hopefully) silent part of the sample.

TempoChange.mod

Current status: OpenMPT passes this test since revision 8732.
Download: TempoChange.mod
Description: ProTracker applies any tempo changes after the first tick (so at one tick per row, they happen on the next row).

VibratoReset.mod

Current status: OpenMPT passes this test since revision 1556.
Download: VibratoReset.mod
Description: Like many other trackers, ProTracker does not advance the vibrato position on the first tick of the row. However, it also does not apply the vibrato offset on the first tick, which results in somewhat funky-sounding vibratos. OpenMPT uses this behaviour only in ProTracker 1/2 mode. The same applies to the tremolo effect.

In total, OpenMPT passes 20 out of 21 tests.