Community > Project / Coder's Corner

The Counting Riddle (sample offset question)

(1/2) > >>

I'm in the process of writing my own web-based tracker and have reached the muddy waters of tracker-variations.

My Question is about the "9" sample offset effect, especially related to special cases when notes and sample number are omitted.
I created a little demo mod that behaves differently in different players.

It's located at

The sample is a voice counting from 1 to 4, depending on the sample offset and the handling of special cases, you get another sequence in different players .

I tested it on multiple trackers and there are 3 different ways the sample offset is handled:

* counting is heard as  2-3-2-3-3-4-4

* Protracker 1.3 - Amiga
* Protracker 2.3d - Amiga and the Windows Clone
* OpenMPT
* counting is heard as 2-3-2-3-2-3-2-3

* Protracker 3.15 - Amiga
* Protracker 4 - Amiga
* Milkytracker (even in Protracker 2 mode)
* counting is heard as 2-3-2-3-1-2-2-3

* FasttrackerII - DOS
* Milkytracker (in Fasttracker mode)
The problem is: I understand the 2nd and the 3th way, but I can't get my head around the logic of the first way (of Protracker 1, 2 and OpenMPT)
especially the note on row 32: this doesn't have a sample number, nor an effect but somehow the previous 9 effect gets applied twice? (the sample starts playing at "three")
Then after that, at row 48, no sample number and "900": you hear "four"? why?

My own code follows Fasttracker here as this seems the most logical implementation (
but most .mod files seem to expect the PT2 way so I would like to get that right.

And even more a mystery: How would you know what playback variation the .mod files expect?

Anyone who has dug deep into this and wants to shed a light?

Oh, look at that, I found a 4th way ...
XMPlay with the the "PT1" playback mode does "2-3-2-3-2-3-3-4"
How balls-on weird is that?
puzzling ...


Small update, before someone says "There's a bug in PT1 and 2 that adds offsets in the 9-effect when no sample number is given".

Yes, I though so too, but not exactly: here's a more simple example with just 2 notes:

If the offset is added, then you would hear "2-3" not "2-4" like you do now on PT1 and PT2, so somehow the offset is tripled.

Still ... puzzling ...


OpenMPT needs to support all of these.

Saga Musix:

--- Quote from: nikku4211 on June 16, 2017, 19:15:25 ---OpenMPT needs to support all of these.

--- End quote ---

Steffest: PT2.3 is messy but its behaviour is by far the most exploited behaviour (that is, some tunes rely on it, but I don't know of any tunes relying on e.g. PT3's behaviour).
Maybe it would help you read my description here:
If that still doesn't help, read OpenMPT's Snd_fx.cpp, look in the function CSoundFile::SampleOffset for SONG_PT_MODE. This deals with the PT1/2 quirks.


OpenMPT needs to support all of these in case some modules exploit each of these sample offset bugs.


[0] Message Index

[#] Next page

Go to full version