-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MOD retrigger effect is broken. #21
Comments
Please note that the various versions of ProTracker do not share the same replayer code and may differ in details when it comes to effect reproduction. ProTracker 2.3d is the most-used version and very few people used ProTracker 3 in comparison, so you should always compare MOD behaviour against ProTracker 2.3d (or bubsy's cross-platform clone of that version). Retrigger in particular is one of those quirky effects that are handled vastly differently between different trackers (as you noticed with FT2). If you want to fix it, I suggest to take a very surgical approach and only fix it one format at a time. |
That is good to know. I just tried a similar test in ProTracker v2.3d and I got the same result as in ProTracker 3 (though I found two versions called "ProTracker v2.3d", I'm not sure which is correct). I'd definitely like to limit these sorts of fixes/tweaks on per-format basis but in this case the current implementation is plain wrong regardless of format. I'd like to at least correct that first. The tracker-specific behavior probably doesn't matter much for that part of things... For reference though, formats aside from MOD/S3M with retrigger currently are implemented with:
if (effect == 0x1b) {
return 0; /* UniEffect(UNI_S3MEFFECTQ,dat) ? */
}
edit: clarification. |
The .MOD (and .XM, .MED, and whatever else uses it...) retrigger effect currently does not initialize the retrigger timer, meaning it will always retrigger on the second tick of a given row.
Test file: in Protracker 3.15, libxmp, OpenMPT, this plays one snare hit, then three evenly spaced snare hits. In MikMod, this plays one snare hit, then four unevenly spaced snare hits. Speed=24, uses
E98
.retrig.mod.zip
The only relevant changelog entry I could find re: this was for libmikmod-3.1.10:
But weirdly, the only change to this effect between libmikmod-3.1.9 and libmikmod-3.1.10 is to prevent it from triggering on tick 0:
libmikmod-3.1.9:
libmikmod-3.1.10:
The worst part of this is that I loaded a test .MOD into Protracker 3.15 and it does retrigger on tick 0.
Test file: this plays one snare, then plays a single snare note with an
E9A
effect on the note line and anE9A
effect on the following line. In Protracker, the two lines withE9A
both play on ticks 0, 10, and 20. libxmp, MikMod, OpenMPT, and MPT 1.16 all do something else(!).retrig2.mod.zip
The first .MOD is trivial to fix (and I have a working patch) but I suspect finding the "correct" behavior for the second .MOD could be a mess, which is why this is an issue and not a PR yet.
edit: I should note that the 3.1.9 behavior is also wrong because it would result in the retrigger timer carrying over between lines, which it shouldn't. To get the behavior of this patch in line with the Protracker 3.15 behavior, the change would probably be to initialize
a->retrig
to 0 instead ofnib
. The FT2 quirks check is correct;E90
does retrigger exactly once in Fasttracker 2 but does not retrigger at all in Protracker.edit 2: initializing
a->retrig
to 0 was actually required anyway so I updated the patch. It does make the playback for the second test identical to Protracker.edit 3: in FT2 the
E9A
s don't play the first note unless there's a note on the line. :(Updated patch to take that into account:
The text was updated successfully, but these errors were encountered: