1.18.00.00 Offset command in XM seems to be bugged

Harbinger · April 06, 2010, 21:11:13

Full Version:
OpenMPT v1.18.00.00

Has the bug occured in previous versions? If yes, please specify version(s): Not sure.

Description of the bug: When testing how XM interacts with Offset commands in Compat and MPT mode, i discovered what i think is unintended behavior. While in Compat mode, Offset commands whose value is larger than the sample size were outright ignored. That's expected. In MPT mode, those same values were processed by playing the note at the end of the sample (i could tell because the channel VU would light up but not play the note).
However, if a normal sample loop was set (with the loop end the same value as the last sample number), the sample loop would not activate -- shouldn't it? With a Bidi loop though, the looping was activated from the END of the Bidi loop -- even if you set the Loop End to NOT the last sample. Here's the kicker: it did this no matter what the 9xx value was (900, 9FF, or anything in between).

How often does it happen?: Always.

How to reproduce (step by step description):
I set up a sample and an instrument in an XM track and tried all tests with different loop settings, between each mode (Compat and MPT). I also called the Offset command with and without the note on the same row, and with different values.

Saga Musix · April 06, 2010, 21:14:52

are you talking about compat or mpt mode? if it's mpt mode, nothing will be changed about that. if it's compat mode, please provide a testcase that verifies that mpt plays stuff different than fasttracker 2 or xmplay.

QuoteWhile in Compat mode, Offset commands whose value is larger than the sample size were outright ignored. That's expected.

not exactly expected, because fasttracker is the only tracker that actually STOPS samples in this case.

Saga Musix · May 23, 2010, 15:16:36

Any news on this from your side?

Harbinger · June 15, 2010, 14:24:33

Still testing. If you know you fixed it, and you are sure it works, you are free to close my Bug Reports, Jojo. You'll know these things a lot quicker than i will. :wink:

Saga Musix · June 15, 2010, 14:32:55

Quote from: "Harbinger"Still testing. If you know you fixed it, and you are sure it works, you are free to close my Bug Reports, Jojo. You'll know these things a lot quicker than i will. :wink:

Well, given the weirdness of FT2, I would rather wait for confirmation from your side if everything is working as intended, since there are all kinds of things which could just go wrong in FT2...

Saga Musix · November 20, 2010, 22:17:48

Another bump. Did you do any further investigation here?

Harbinger · November 22, 2010, 20:40:44

Negative. Other things have leapfrogged this on my priority list. That's why i said if it's good enough for you, it's good enough for me. Besides i did this test only to do the proper write-up in the OHM...

Saga Musix · March 13, 2013, 16:45:16

I'll move this to the closed issues since I still can't reproduce it, and there's nothing in the offset code which would induce such a behaviour. The only thing I can think of is that you might have sticked a high offset comment somewhere in the module and thus sample offsets were not the expected ones...