TakeTracker / FastTracker notes and format ( 32 channel .mod files)

TakeTracker introduced the “10CH” to “16CH” format, Fast Tracker 2 increased this to “32CH”, for less than 10 channels the “2CHN” to “9CHN” magic bytes/id is used.

These trackers use the Protracker format and Effect Commands however they are NOT 100% compatible as they do not implement any of the widely used quirks (so music like 4-Mat's chip tunes wont work) and the sample loop modes are not present and no DMA Wait behaviour.

This in effect renders them Protracker incompatible and these trackers should not be used to write a Protracker module and vice-versa.

TakeTracker introduces 2 more octaves, one above and one below that defined in Ultimate Soundtracker, however the lowest octave is all but worthless being less that 4Khz in sampling rate.

I have extracted all the valid notes and their note periods from TakeTracker (by creating a .mod with all notes and extracting them from a hex editor):

Notice that the display names and period values line up with Ultimate Soundtracker/Protracker series but not FastTracker 2.

I extracted and converted the TakeTracker finetune note period table (from the .exe) into a format similar to Protracker.

// Fine tuning 0, normal.
1712, 1616, 1524, 1440, 1356, 1280, 1208, 1140, 1076, 1016, 960, 906, 856, 808, 762, 720, 678, 640, 604, 570, 538, 508, 480, 453, 428, 404, 381, 360, 339, 320, 302, 285, 269, 254, 240, 226, 214, 202, 190, 180, 170, 160, 151, 143, 135, 127, 120, 113, 107, 101, 95, 90, 85, 80, 76, 72, 68, 64, 60, 56, 0
// Fine tuning 1
, 1700, 1604, 1514, 1430, 1348, 1274, 1202, 1134, 1070, 1010, 954, 900, 850, 802, 757, 715, 674, 637, 601, 567, 535, 505, 477, 450, 425, 401, 379, 357, 337, 318, 300, 284, 268, 253, 239, 225, 213, 201, 189, 179, 169, 159, 150, 142, 134, 126, 119, 113, 106, 100, 94, 89, 84, 79, 75, 71, 67, 63, 59, 56, 0
// Fine tuning 2
, 1688, 1592, 1504, 1418, 1340, 1264, 1194, 1126, 1064, 1004, 948, 894, 844, 796, 752, 709, 670, 632, 597, 563, 532, 502, 474, 447, 422, 398, 376, 355, 335, 316, 298, 282, 266, 251, 237, 224, 211, 199, 188, 177, 167, 158, 149, 141, 133, 125, 118, 112, 105, 99, 93, 88, 83, 78, 74, 70, 66, 62, 59, 56, 0
// Fine tuning 3
, 1676span>, 1582, 1492, 1408, 1330, 1256, 1184, 1118, 1056, 996, 940, 888, 838, 791, 746, 704, 665, 628, 592, 559, 528, 498, 470, 444, 419, 395, 373, 352, 332, 314, 296, 280, 264, 249, 235, 222, 209, 198, 187, 176, 166, 157, 148, 140, 132, 125, 118, 111, 104, 99, 93, 88, 83, 78, 74, 70, 66, 62, 59, 56, 0
// Fine tuning 4
, 1664, 1570, 1482, 1398, 1320, 1246, 1176, 1110, 1048, 990, 934, 882, 832, 785, 741, 699, 660, 623, 588, 555, 524, 495, 467, 441, 416, 392, 370, 350, 330, 312, 294, 278, 262, 247, 233, 220, 208, 196, 185, 175, 165, 156, 147, 139, 131, 124, 117, 110, 104, 98, 92, 87, 82, 77, 73, 69, 65, 62, 58, 56, 0
// Fine tuning 5
, 1652, 1558, 1472, 1388, 1310, 1238, 1168, 1102, 1040, 982, 926, 874, 826, 779, 736, 694, 655, 619, 584, 551, 520, 491, 463, 437, 413, 390, 368, 347, 328, 309, 292, 276, 260, 245, 232, 219, 206, 195, 184, 174, 164, 155, 146, 138, 130, 123, 116, 109, 103, 97, 92, 87, 82, 77, 73, 69, 65, 61, 58, 56, 0
// Fine tuning 6
, 1640, 1548, 1460, 1378, 1302, 1228, 1160, 1094, 1032, 974, 920, 868, 820, 774, 730, 689, 651, 614, 580, 547, 516, 487, 460, 434, 410, 387, 365, 345, 325, 307, 290, 274, 258, 244, 230, 217, 205, 193, 183, 172, 163, 154, 145, 137, 129, 122, 115, 109, 102, 96, 91, 86, 81, 77, 72, 68, 64, 61, 57, 56, 0
// Fine tuning 7
, 1628, 1536, 1450, 1368, 1292, 1220, 1150, 1086, 1026, 968, 914, 862, 814, 768, 725, 684, 646, 610, 575, 543, 513, 484, 457, 431, 407, 384, 363, 342, 323, 305, 288, 272, 256, 242, 228, 216, 204, 192, 181, 171, 161, 152, 144, 136, 128, 121, 114, 108, 102, 96, 90, 85, 80, 76, 72, 68, 64, 60, 57, 56, 0
// Fine tuning -8
, 1814, 1712, span style="color: #CC0000;">1616, 1524, 1440, 1356, 1280, 1208, 1140, 1076, 1016, 960, 907, 856, 808, 762, 720, 678, 640, 604, 570, 538, 508, 480, 453, 428, 404, 381, 360, 339, 320, 302, 285, 269, 254, 240, 226, 214, 202, 190, 180, 170, 160, 151, 143, 135, 127, 120, 113, 107, 101, 95, 90, 85, 80, 75, 71, 67, 63, 60, 0
// Fine tuning -7
, 1800, 1700, 1604, 1514, 1430, 1350, 1272, 1202, 1134, 1070, 1010, 954, 900, 850, 802, 757, 715, 675, 636, 601, 567, 535, 505, 477, 450, 425, 401, 379, 357, 337, 318, 300, 284, 268, 253, 238, 225, 212, 200, 189, 179, 169, 159, 150, 142, 134, 126, 119, 112, 106, 100, 94, 89, 84, 79, 75, 71, 67, 63, 59, 0
// Fine tuning -6
, 1788, 1688, 1592, 1504, 1418, 1340, 1264, 1194, 1126, 1064, 1004, 948, 894, 844, 796, 752, 709, 670, 632, 597, 563, 532, 502, 474, 447, 422, 398, 376, 355, 335, 316, 298, 282, 266, 251, 237, 223, 211, 199, 188, 177, 167, 158, 149, 141, 133, 125, 118, 111, 105, 99, 94, 88, 83, 79, 74, 70, 66, 62, 59, 0
// Fine tuning -5
, 1774, 1676, 1582, 1492, 1408, 1330, 1256, 1184, 1118, 1056, 996, 940, 887, 838, 791, 746, 704, 665, 628, 592, 559, 528, 498, 470/span>, 444, 419, 395, 373, 352, 332, 314, 296, 280, 264, 249, 235, 222, 209, 198, 187, 176, 166, 157, 148, 140, 132, 125, 118, 111, 104, 99, 93, 88, 83, 78, 74, 70, 66, 62, 59, 0
// Fine tuning -4
, 1762, 1664, 1570, 1482, 1398, 1320, 1246, 1176, 1110, 1048, 988, 934, 881, 832, 785, 741, 699, 660, 623, 588, 555, 524, 494, 467, 441, 416, 392, 370, 350, 330, 312, 294, 278, 262, 247, 233, 220, 208, 196, 185, 175, 165, 156, 147, 139, 131, 123, 117, 110, 104, 98, 92, 87, 82, 78, 73, 69, 65, 61, 58, 0
// Fine tuning -3
, 1750, 1652, 1558, 1472, 1388, 1310, 1238, 1168, 1102, 1040, 982, 926, 875, 826, 779, 736, 694, 655, 619, 584, 551, 520, 491, 463, 437, 413, 390, 368, 347, 328, 309, 292, 276, 260, 245, 232, 219, 206, 195, 184, 174, 164, 155, 146, 138, 130, 123, 116, 109, 103, 97, 92, 86, 82, 77, 73, 69, 65, 61, 58, 0
// Fine tuning -2
// B-4 = 57? seems a bit odd, values for fine tune -3 & -1 are both 58.
, 1736, 1640, 1548, 1460, 1378, 1302, 1228, 1160, 1094, 1032, 974, 920, 868, 820, 774, 730, 689, 651, 614, 580, 547, 516, 487, 460, 434, 410, 387, 365, 345, 325, 307, 290, 274, 258, 244, 230, 217, 205, 193, 183, 172, 163, 154, 145, 137, 129, 122, 115, 108, 102, 96, 91, 86, 81, 77, 72, 68, 64, 61, 57, 0
// Fine tuning -1
, 1724, 1628, 1536, 1450, 1368, 1292, 1220, 1150, 1086, 1026, 968, 914, 862, 814, 768, 725, 684, 646, 610, 575, 543, 513, 484, 457, 431, 407, 384, 363, 342, 323, 305, 288, 272, 256, 242, 228, 216, 203, 192, 181, 171, 161, 152, 144, 136, 128, 121, 114, 108, 101, 96, 90, 85, 80, 76, 72, 68, 64, 60, 58
// Random data after finetune table (for Finetune -1 on sample + B-4 + Arpeggio).
// But currently don't think this is a bug that needs emulating (TakeTracker's code may handle this correctly, difficult to tell in Dosbox with SB at 21Khz).
, 0x220, 0xb, 0x1, 0xac44, 0xa0c8, 0x96bb, 0x8ddd, 0x85fc, 0x7eee, 0x7896, 0x72d8, 0x6d9f, 0x68db, 0x647d, 0x6078, 0x5cc2

As the Fine Tune Table is rather large and does not include those Period Values for FT2 “CHxx” modules it is better to use a formular to calculate the period values.

There can be slight differences between a (very) few values, but I don't think they are of consequence.

Fine Tune allows you to tune a sample 1/8 of a semi-tone (a note) * FineTuneValue up or down. So its 0-7/8ths up and 1-8/8ths down (-8/8ths is an entire semi tone down - a note).

Lars Hamre defines this as:

Note Period * ( 2^( -FineTune / 12 / 8 ) )

Where 12 notes per octave, 8 semi-tones.

The values should be rounded to integer values (Amiga only takes integer period values).

Some examples: Protracker C-1 is 856 note period, fine tune -8 should drop it to 907 the note below.

856 * ( 2^( - -8 / 12 / 8 ) )
=
856 * 1.059463094
=
906.900408464
=
907 rounded.

Protracker C-1 is 856 note period, fine tune 7 should take it to 814.

856 * ( 2^( - 7 / 12 / 8 ) )
=
856 * 0.950714015
=
813.81119684
=
814 rounded.

Where it doesn't match the Protracker fine tune table is for B-3, 113 note period, fine tune 7 should be 108.

113 * ( 2^( - 7 / 12 / 8 ) )
=
113 * 0.950714015
=
107.430683695
=
107 rounded, out by one.

When applied to the TakeTracker range A#4 is 60 note period (B-4, 56 note period for positive fine tune values does not change, always 56), fine tune 7 should be 57.

60 * ( 2^( - 7 / 12 / 8 ) )
=
60 * 0.950714015
=
57.0428409
=
57 rounded.

So the formula appears good for TakeTracker's FineTune table too.

Fasttracker 2 introduces 3 more octaves for 8 octaves in total, two above and one below that defined in TakeTracker. Also the Middle C is now in the correct position.

I have extracted all the valid notes and their note periods from Fasttracker (by creating a .mod with all notes and extracting them from a hex editor):

Notice: That notes C-0 to G#0 inclusive are unusable in a .mod format because the values are outside the 12bit range allowed to store the note period. They are 13bit values where the upper bit corrupts the instrument number (so instrument 0x1 becomes instrument 0x11 in the pattern). HOWEVER Fasttracker 2 will allow you to use these notes and then save a (potentially) corrupt modules, unless those notes are used with a instrument numbers 16 to 31.

Notice 2: That TakeTracker uses some slightly different Period Values (F#6 to A-6). Which could be used to identify the origins of the module (although what happens if you load and then save from FT2?).

Fasttracker2 does not support the much needed quirks that appear in Protracker 2. Hence it cannot be called Protracker compatible even though it uses the same effect commands. There are just far too many modules that use these quirks and wont play correctly in Fasttracker 2.

Effect 9xx Set Sample Offset behaves quite different from Protracker 2.

It will not remember the Set Sample Offset, or add the value again after the sample has started playing. It will reuse the set value if the command 900 is encountered. Note Delay (EDx) is not affect and neither is Retrigger Note (E9x).

FT2 limits the arpeggio range to the maximum note B-7 + one (what appears to be) note. This can be double checked by playing the maximum note when the fine tune is set to +127 and any arpeggio value. The tone of the note does not change.

Although the Protracker M.K. module is limited to 64 patterns the file format actually supports 256 different patterns (although rather pointless as the song sequence only has 128 slots), the limit is imposed by the Protracker Editor, not the replay routine.

The Protracker also has the “M!K!” format, which is identical to the M.K. format expect for having up to 100 patterns (the file finger print is also changed to “M!K!”).

Fasttracker 2 will allow you to save up to 256 patterns and only issue a warning when trying to save a module with more than 100 patterns. The warning does not stop the module from being saved and FT2 will happily save all 256 patterns correctly.

When saving a 4 channel modules in FT2 it will ALWAYS place the “M.K.” finger print within the module, no matter the number of patterns (at no point does it use “M!K!”).

Fasttracker introduces the Panning Command (8xx and E8x). There are 256 panning position, 0 = maximum left, 255 = maximum right and 128 = middle.

Some modules, use a 7 bit panning, 800 = left, 840 = middle & 880 = right.

There are two commands for setting the channel position:

Sets the panning position to the provided value.

Once set the channel maintains that position until the next command (it is not reset upon a new note).

Unusually for a extended command this does not “fine set” the panning position, it is a coarse setting (this command also certainly exists due to the Gravis Ultrasound only having 16 panning positions per channel). Sets the panning position to the provided value * 16.

Once set the channel maintains that position until the next command (it is not reset upon a new note).

There is an issue with this command due to the lower nibble being missing, E80 is full left, E88 is middle but E8F is NOT full right. Due to 0xF * 16 = 0xF0, which is not 0xFF which is full right.

On the Gravis Ultrasound, it only has 4-bit panning position PER channel, setting the channel to 0xf makes makes it FULL right (although there is nothing stopping you using two channels playing the same sample one full left the other full right and THEN adjusting the volume levels giving you 10 bit panning position [volume command is 6-bit + 4-bit panning position]).

Here is a list of created test modules for Black Box Testing against TakeTracker and FastTracker 2. They are based upon a set created and (sadly) thrown away/unmaintained to confirm the behaviour of the Protracker series on the Amiga. I have enhanced/recreated them with non-commercial samples (previously, stupidly, I grabbed what ever sample was at hand and so could not release them). The speech samples are created with the open source “espeak” library.

These notes are rather difficult to follow without the modules and the modules really need this notes to explain what is going on (due to the limited amount of space for text in a module). So you need both!

There is behaviour associated with the Arpeggio command.

1) That Tick Speed 1 will ignore the Arpeggio Command entirely (or more precisely there are no other ticks to use the arpeggio on, as the implementation is solely dependant upon Tick Speeds) and only the base note (from the note column) is played.

2) That Tick Speed 2 will only play the base note (from the note column) and the first Arpeggio value (highest nibble) of the Effect Data, the second Arpeggio value is ignored (the lower nibble) of the the Effect Data.

3) That a wrap round of the note occurs if a combination of a high note and arpeggio combine to take the note past the maximum playable note in Protracker (B-3). If a wrap round occurs the note will be played with a fine tune +1 onto the existing fine tune (with the exception of fine tune 7 which changes to fine tune -8). This occurs due to the fine tune tables being adjacent in memory so when the arpeggio command reaches past the maximum note of one fine tune table it reaches the lowest notes of the next fine tune table.

4) In the Protracker Editor (not the stand alone replay routine) the note period table contains a note period of zero in between each fine tuning table. This allows you to actually stop the sample for an entire tick and then start it again (so on a tick speed of 2 it will stop and start the sample). This can be used to play a sample more slowly (a crude time stretching). For example using B-3 with a arpeggio of 1 causes the note period to be zero for a single tick, you can use any note where the resulting arpeggio lands on the same note (where C-4 would be). So C-3 + 12 arpeggio results in a note period of zero.

When the module is played in Protracker 2.x series you will hear in Pattern 0:

In Pattern 1 and 2 the note wrap round is checked (pattern 1):

Pattern 2 continues playing the arpeggio scale:

Pattern 3 Checks that the zero note period is present by “time stretching” the sample:

Results:

Taketracker only seems to see column 2 of the arpeggio command, it is ignoring column 1 at tick speed 2.

Protracker inherits note suppression from Ultimate Soundtracker as it still uses a software loop to wait for samples to end. This is the DMA Wait value which defaults to 300 in Protracker 2.x. It should be noted that Protracker 3.x uses a completely different (and better) system for wait for samples to end and so behaves differently.

Cycle exact emulation is required to capture this bug perfectly as its dependant of where the CPU cycle execution is in relation to the scan-line, because the DMA Audio is fetched from memory at the beginning of each scan-line. And according to the Amiga Hardware Reference Manual page 141, section ”Stopping the Audio DMA” it says ”If the DMA channel is disabled for a very short time (less that two sampling periods) it may stay on and thus continue from where it it left off.”.

Without cycle exact emulation it is still possible to calculate when this is going to occur, when twice the note period is greater than the DMA Wait value in time. Under normal circumstances its not even an issue, as the lowest note, note C-1 has a period of 856. A DMA Wait of 300 requires 3000 CPU Clock Cycles (300 * “dbra D0,mt_WaitDMA” instructions where “dbra” takes 10 clock cycles each). Because 856 * 2 is still less than 3000 it should not be a problem right? Wrong.

(As a side note this is why you need to increase the DMA Wait value in Protracker 2.x for faster Amigas, as the default 300 waits might be executed in only 500 equivalent clock cycles causing Note Suppression to occur. Its also why it was improved and eliminated in the Protracker 3.x series.)

The problem rears its ugly head when the Arpeggio command is used, in Ultimate Soundtracker it allows you to “reach” pseudo random data past the end of the note table, e.g. the maximum note B-3 plus 15 notes of Arpeggio.. In protracker this can only occur when using a Fine Tune of -1, as this is the last note table in memory. These out of bound areas are different for the stand alone replay routine and the Protracker Editor. Luckily the Protracker Editor is static data so is easy to replicate, the stand alone replay routine uses this area of memory to store Channel 0's variables.

So although its really unlikely it is still possible to create a Note Suppression in PT2.x.

When the module is played in Protracker 2.x series you will hear in Pattern 0:

Due to Taketracker and Fasttracker 2 adding an extra octave above the highest octave Protracker 2.x has Arpeggio is not going to cause a note suppression. It is possible (albeit unreliable) to create a note suppression using the the 1xx Note Portamento command. As it is possible to subtract a large enough value to cause the Note Period value to wrap around to the lowest note. The note period is stored as a 12 bit number, the highest note at -1 fine tune is 114, so a (114 - 115) & 0xfff = 4095 which is a very low note.

In Pattern 1:

You may need to lower the DMA Wait value in Protracker 2.x to hear this method consistently depending on setup (yes I know that cheating!), at the time of writing WinUAE emulates DMA Wait Bug correctly (and has done for quite some time) if Cycle Exact mode is enabled.

+Where “Ss” is the “Suppressed” sample starting but not getting past the first letter S (kinda sounds like a high hat).
++Where “Su” is the “Suppressed” sample with Arpeggio for the next octave up.

Exposes the Set Sample Offset Quirks in Protracker 2.x. Notice that this command behaves differently in ALL major versions of Protracker (1.x, 2.x, 3.x). I have not spent enough time with Protracker 1.x to solidly confirm its behaviour.

This module exposes that Protracker 2.x adds the Sample Offset in the 9xx command BEFORE and AFTER use.

Using a single sample contains the words “Five four three two one” you should hear the following in Protracker 2.x in Pattern 0 which just tests the Sample Offset Command 9xx:

In Protracker 2.x the 9xx command sets the sample offset for the current sample, so as long as you don't change the instrument number (is NOT present) THE SAMPLE WILL PLAY FROM THE SET ADDRESS!

Pattern 1 tests that the Set Sample Offset Command also affect the Note Delay (EDx) and Retrigger Note (E9x) commands. Again as long as the instrument number is not changed (or present):

+You probably wont hear the E93 sample retrigger for “Four-Four three two one” as it occurs in on a silent part of the sample.

Check that the Vibrato waveforms of Protracker 2.x are supported and move in the right direction.

Protracker 2.x lists 4 different waveform types, however only 3 were ever implemented - but the documentation did not change.

1. Sinewave (default)
2. Sawtooth (Ramp down)
3. Square
4. Random (Not implemented and Square waveform gets used instead).

Pay attention to the direction of the pitch change when the note starts, not all soundtrackers vibrate in the same direction (looking at you OpenMPT 1.22.2!).

*Taketracker does not support the command Vibrato Waveform Control (E4x) and so can only play the default sinewave which is always retriggered on every row which contains a Vibrato command (4xx). Thus sounds completely bugged.

In Protracker there is a typo in the Tremolo code, where a minor variable is mistakenly pointing at a Vibrato variable. So under certain (admittedly rather rare) conditions it is possible to make the Tremolo Sawtooth waveform go up instead of down (its only meant to go down, that is fade out).

This test creates the conditions for making the Sawtooth waveform fade in. Which is a

Repeat test but without continuous Vibrato (Row 13 is the only difference)

+There is an additional bug in the Protracker Editor which causes the volume level to be reset on tick 0 when the Tremolo command is used (causing a sort of click per row). This bug is not present in the stand alone replay code.
++Taketracker does not support the Vibrato Waveform Control command (E4x) or Tremolo Waveform Control command (E7x). Also the Tremolo command (7xx) seems quite wrong.

In Protracker 2.x series executing a Pitch Bend command (1xx or 2xx) in the same row as a Row Delay command (EEx) is completed smoothly, as if additional rows had been inserted containing the Pitch Bend command.

Pattern 0 tests that a row skip occurs when combining Row Delay with Pattern Break commands.

The Pitch Bend Up from Rows 00 to 09 should be continuous and a smooth transition, same for the Pitch Bend Down on Rows 12 to 21. The Row Delay should not interfere with the Pitch Bend.

NOTE: Taketracker 0.9e's documentation does not list the Row Delay command (EEx) as supported, however this test passed correctly Row Delay worked correctly.

In Protracker 2.x series executing a Volume Slide command (Axx) in the same row as a Row Delay command (EEx) is completed smoothly, as if additional rows had been inserted containing the Volume Slide command.

Pattern 0 tests that a row skip occurs when combining Row Delay with Pattern Break commands.

The Volume Slide Down from Rows 00 to 09 should be continuous and a smooth transition, same for the Volume Slide Up on Rows 12 to 21. The Row Delay should not interfere with the Volume Slide.

NOTE: Taketracker 0.9e's documentation does not list the Row Delay command (EEx) as supported, however this test passed correctly Row Delay worked correctly.

In Protracker 2.x series executing a Fine Pitch Bend command (E1x or E2x) in the same row as a Row Delay command (EEx) will occur multiple times - once for each Row to Delay, as if additional rows had been inserted containing the Fine Pitch Bend command.

Pattern 0 tests that a row skip occurs when combining Row Delay with Pattern Break commands.

The Pitch Bend Up from Rows 00 to 09 should be continuous and a smoothish transition, albeit stepped as the Pitch Bend only occurs on Tick 0, same for the Pitch Bend Down on Rows 12 to 21. The Row Delay should not interfere with the Pitch Bend.

-Fasttracker 2 only applied the Fine Pitch Bend once on the first Row with the Row Delay Command (EEx), so if EE6 is used 5 Fine Pitch Bend commands are effectively ignored when compared to Protracker 2.3a.

NOTE: Taketracker 0.9e's documentation says it supports Fine Pitch Bend (E1x is listed twice, so assume its a typo for E2x) but does not say it supports the Row Delay command (EEx). However it appears that Taketracker does support the Row Delay command (EEx) but NOT Fine Pitch Bend (E1x or E2x). So the test fails.

In Protracker 2.x series executing a Fine Volume Slide command (EAx or EBx) in the same row as a Row Delay command (EEx) will occur multiple times - once for each Row to Delay, as if additional rows had been inserted containing the Fine Volume Slide command.

Pattern 0 tests that a row skip occurs when combining Row Delay with Pattern Break commands.

The Fine Volume Slide down from Rows 00 to 09 should be continuous and a smoothish transition, albeit stepped as the Fine Volume Slide only occurs on Tick 0, same for the Fine Volume Slide up on Rows 12 to 21. The Row Delay should not interfere with the Volume Slide.

-Fasttracker 2 only applied the Fine Volume Slide once on the first Row with the Row Delay Command (EEx), so if EE6 is used 5 Fine Volume Slide commands are effectively ignored when compared to Protracker 2.3a.

In Protracker 2.x series executing a Pattern Break command (Dxx) in the same row as a Row Delay command (EEx) causes the Pattern Break to add one row on (Dxx +1). This can even cause an entire pattern to be skipped.

Pattern 0 tests that a row skip occurs when combining Row Delay with Pattern Break commands.

Pattern 1 tests that a pattern skip occurs when combining Row Delay with Pattern Break to the last row of a pattern.

Pattern 2 is skipped entirely because of Pattern 1 Row 13 commands.

Pattern 3

NOTE: Taketracker 0.9e's documentation does not say it supports the Row Delay command (EEx) but it does. Its Pattern Break command (Dxx) does no jump to the desired row, it behaves as originally defined in DOC Soundtracker 2.2 which is to go to row 0 of next pattern, no row skip occurs.

Mahony and Kaktus changed the way samples in Soundtracker are looped when they created Noisetracker. Protracker inherits their sample looping behaviour.

1. If the sample loop start point is zero, then the entire sample is played before looping. This includes sample data OUTSIDE the loop points.
2. Sample Chaining. It is possible to switch between looped samples by just changing the instrument number. The switch occurs when the current sample loop end is reached. The new sample is played from its loop start address.
3. Switching to a non-looped sample results in silence, technically on the Amiga its playing the first two bytes which are zero'd out by the replay routine upon initialisation. Which means you can switch back to a loop sample and start playing it.

In Protracker 2.x for Pattern 0 you will hear, where * means this part of the sample is looped “One (Five*)” means the word “One” is heard followed by “Five” which is repeated endlessly:

Pattern 1:

Pattern 2: