Print

[Saga Musix]

Yes, ptoffset.mod features some of the bugs found in Professional Tracker and I think goes a bit beyond that - if the file plays correctly, you can be sure that you got ProTracker-style offset 99% right.

[Radium Editor]

But the question is if "Professional Tracker" exploits the protracker bug exposed in ptoffset.mod, where it adds the offset both before and after playing the sample. Otherwice, I'm relatively confident that Radium does things correctly, and I can't hear any difference between Protracker and Radium now, except for those instrument vs. channel clashes.

Edit: I've looked through the module now, and I can't find any usage of that bug. For the bug to work, the 9xx-command must be on the same line as a note and a non-null sample number, but everywhere in this module, as far as I can see, 9xx-commands have been explicitly placed on their own lines before notes with sample number 0 are used.

[Saga Musix]

It's the same bug really. It just depends on the viewpoint. The description of the bug on the wiki is just very basic, and not exactly identical to how it should be implemented.

[Radium Editor]

It's the same bug really. It just depends on the viewpoint.

Sorry, same bug as what?

[Saga Musix]

The bug that is demonstrated by ptoffset.mod is exactly what is being abused in Professional Tracker, but the latter may not exploit all possible combinations of offset commands. ptoffset.mod tests all relevant cases.

[Radium Editor]

The bug that is demonstrated by ptoffset.mod is exactly what is being abused in Professional Tracker,

Really? I can not find that bug being triggered in "Professional Tracker" anywhere. Can you be specific about exactly when this happens?

but the latter may not exploit all possible combinations of offset commands. ptoffset.mod tests all relevant cases.

Sure, ptoffset.mod is a fine test, and apart from the bug in protracker that it exposes, Radium plays it perfectly.

[Saga Musix]

For example, line 0-2 corresponds to the pattern transition 62-63 in Professional Tracker: The noise sample on channel 1 is triggered with an offset effect in pattern 62 and then pattern 63 triggers the note again without an instrument number, so it plays the noise part of the sample again.
Line 8-10 corresponds to pattern 5 in Professional Tracker.
Line 16 tests if effect memory is applied correctly. This is probably not used in Professional Tracker but is also probably you get right automatically.

[Radium Editor]

Thanks for the explanation, but I have no trouble understanding what happens in ptoffset.mod or "Professional Tracker".  

 I've only been asking if the protrfacker offset BUG happens in the module "Professional Tracker"?

You don't need to answer that though, because I've looked through the module and couldn't find any use of the bug, so I just assume that there's nothing wrong with latest youtube video I uploaded of "Professional Tracker" two days ago, except for the 5 known occurences of a channel vs. instrument-bug, which is irrelevant to ptoffset.mod.

EDIT: "no trouble understanding" was an exaggeration. It's a bit hairy, but I know what happens. The point for asking about whether the protracker offset bug happens in this module, is whether I need to add a note in the youtube video about it not being played back correctly, since the protracker offset bug is not supported in the module importer in radium.

[Saga Musix]

Now I'm confused, maybe we need to clear up terminology again.
By ProTracker offset bug I consider any weird offset logic, including the one that is exploited in Professional Tracker. I think you only consider the part where the offset is doubled after a note + instrument number + offset combination is found? If so, then this is indeed not exploited in Professional Tracker.

[Radium Editor]

Exactly. That's the bug. I did try to define the terminology though. On the last post of page 1, I quoted the description of ptoffset from the link you gave, and in the next post I wrote: "But the question is if "Professional Tracker" exploits the protracker bug exposed in ptoffset.mod, where it adds the offset both before and after playing the sample". The other behaviors doesn't necessarily seem like bugs to me.

Guess it could have been clearer though. Glad we cleared this up.