STK: Axx is incorrectly interpreted as D00 in some files

[bryc]

This STK here is jumping constantly with D00 commands. SLL-high byte.zip

[8bitbubsy]

I'm fully aware, and this is too complicated to have an elegant fix. Identifying what tracker a 15-sample .mod was created with is based on hackish heuristics.

[bryc]

ah that sucks. this is a major bug in playback. but this file played fine in a 2017 version i had laying around. i guess you hit the limit of STK compatibility? :(

[8bitbubsy]

While the older version may have loaded those exact modules correctly, it also failed on more modules than the modern version does. Getting Axx/Dxx right in STK import is a challenge. They were mixed in different STK tracker versions.

[bryc]

So what are your intentions for this? I see now how it can be hacky, as I'm working on a stk>mod converter. In case of 'high byte', checking if Dxx has data where xx is, it obviously can't be a pattern break, since specific row support did not come until ProTracker 1.1. The usage of D makes no sense in that file.

The most elegant solution is to just support DOC+ only, since that is when the commands started being 'standard'. No heuristics or guessing necessary. And if that's the case, this issue can be closed and I'll know which STK files are worthy to report bugs on ;)

[8bitbubsy]

Your assumption about Dxx is wrong. Just because any Dxx parameter would yield the same result doesn't mean you couldn't accidentally type a value in a Dxx in the tracker. I bet the saver didn't sanitize any effect parameters. In fact, I actually did stumble upon an STK .MOD where a Dxx with a value is found, but it has to be converted to D00.

[8bitbubsy]

My intentions are not very defined, but I guess I want to support loading "most" of the STK modules out there. In reality it works a bit different since it's so hard to get them all to load correctly. This is why I look at this as a hackish import instead of a proper load.