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.
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 might invalidate the description. 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.
- 1 AmigaLimitsFinetune.mod
- 2 ArpWraparound.mod
- 3 DelayBreak.mod
- 4 finetune.mod
- 5 InstrDelay.mod
- 6 NoteDelay-NextRow.mod
- 7 PatLoop-Break.mod
- 8 PatternJump.mod
- 9 PortaSmpChange.mod
- 10 PortaSwapPT.mod
- 11 PortaTarget.mod
- 12 PTInstrSwap.mod
- 13 ptoffset.mod
- 14 PTSwapEmpty.mod
- 15 TempoChange.mod
- 16 VibratoReset.mod
Current status: OpenMPT passes this test since revision 1555.
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, ScreamTracker 3 always clamps periods to the same range in its Amiga mode. This test file should stay completely in tune at all times.
Current status: OpenMPT passes this test since revision 1537 + 6738.
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.
Current status: OpenMPT passes this test since revision 2108.
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.
Current status: OpenMPT currently fails this test.
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.
Current status: OpenMPT passes this test since revision 4212 + 8653 + 8674.
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.
Current status: OpenMPT passes this test since revision 8730.
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).
Current status: OpenMPT passes this test since revision 5402.
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”.
Current status: OpenMPT passes this test since revision 1321.
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”.
Current status: OpenMPT passes this test since revision 3578.
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.
Current status: OpenMPT passes this test since revision 6614 + 8665.
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.
Current status: OpenMPT passes this test since revision 4726.
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.
Current status: OpenMPT passes this test since revision 4223.
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.
Current status: OpenMPT passes this test since revision 4018.
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.
Current status: OpenMPT passes this test since revision 4950.
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.
Current status: OpenMPT passes this test since revision 8732.
Description: ProTracker applies any tempo changes after the first tick (so at one tick per row, they happen on the next row).
Current status: OpenMPT passes this test since revision 1556.
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 15 out of 16 tests.