More player bugs

[bryc]

Here is a list so far of modules that are played wrong in some way. I'll add more as I find them

XM

1. Xerxes/minors&majors.xm (Notes cut a bit too early)
2. Lamb/among the clouds.xm (Ambient SFX not playing properly)

MOD

1. Muttley/zo zad.mod (xmplay also plays wrong, sorcery is going on here)

STK

1. SLL/high byte.mod (since you support STK, here's a headache to rethink that decison ;) )

---

I'm not sure if any of these use quirks that you don't wish to support, so just cross any out that are intentionally broken. :-)

[steffest]

Interesting!
Thanks.

1. Xerxes/minors&majors.xm (Notes cut a bit too early)

Indeed. It appears at the "note-off" command, the volume envelope doesn't jump to the correct sustain point. That's an interesting one as it appears to be a bug.

2. Lamb/among the clouds.xm (Ambient SFX not playing properly)

This is because the L command (set envelope point) is not implemented yet. It's listed in the readme as missing feature. Still on the todolist, but not very high priority. (First time I see this used actually, but I'm sure there are other XM files that use this)

1. Muttley/zo zad.mod (xmplay also plays wrong, sorcery is going on here)

Yes... the F20 command was a proper bug, that is fixed in c30d8cc

The other issue are related to the rather extreme tempo switches that influence the - also rather extreme - arpeggio commands on the small loops.
It's a known issue - annotated here https://github.com/steffest/BassoonTracker/blob/master/script/src/tracker.js#L1279
Also on the TODO, although there's no easy fix ... needs some rethinking/restructuring.

STK

1. SLL/high byte.mod (since you support STK, here's a headache to rethink that decison ;) )

Yeah.. Sountdtracker is a bit "supported by accident"
The original soundstrack had a bit different commands. Like pitch slide is combined into 1 "2" command, both for up and down, Arpeggio is 1 instead of 0 ...
So there should be some conversion which is not happening now.
That being said: this mod also uses D commands, which wasn't supported in the original SoundTracker I think, so I have no idea what tracker was used to create this mod.
Anyway: good one! I'll put it on the list, should be somewhat straightforward to fix.

Thanks!

[bryc]

That being said: this mod also uses D commands, which wasn't supported in the original SoundTracker I think, so I have no idea what tracker was used to create this mod.

Commands D and E are Volume Slide Up/Down in TJC/DFJ. DOC scrapped them and used D as "pattern break". Command "A" was added later for volume slide, so OpenMPT translates it D>A. It seems they accomplish this by counting how many D commands are used, or how much empty space is after a D command. Since 'high byte' is full of D commands, it can be inferred "wait, this is not a pattern break". But these are heuristics and considered hacky/inelegant. Specially crafted files, or even the odd wild one, may defeat heuristics. This page explains the entire changelog of ST better than I can.

It's basically up to you how far you want to go down the rabbit hole ;). I imagine a perfect solution for every case would be quite verbose and labor intensive to test. While some of the later STK files are very close to MOD.

Yes... the F20 command was a proper bug, that is fixed in c30d8cc

Wow, nice simple fix!

This is because the L command (set envelope point) is not implemented yet.

Yeah I was worried about that since some XM features aren't implemented. At least one was a real bug :) I'll keep your unimplemented feature list at hand when checking further XMs.

[bryc]

Doing more testing with another XM player and found yours had the same issue:

dune&orange - mark a.j. pisses off.xm

• Pattern 3, Channel 10 - instrument volume fade handled incorrectly, resulted in distorted sound. Effect is Retrigger Note.

[steffest]

• Pattern 3, Channel 10 - instrument volume fade handled incorrectly, resulted in distorted sound. Effect is Retrigger Note.

Ah! Excellent example - Thanks.
That's indeed a player incompatibility that should be fixed.
I'll look into it.

[bryc]

Also here is a test case that BassoonTracker fails: InsChangeEnvNotChangeNoteOff.zip

If a lone instrument without a note plays after a previous instrument with a note has played, it should retrigger or reset envelope of the last instrument with a note, and ignore the actual specified instrument value. The actual sample position must be retained, and not reset to 0.

BassoonTracker seems to both ignore retriggering the envelope, but seems to react to a different sample map in a changed instrument.

In a different library I am testing, it retriggers the envelope using the new instrument's envelope (wrong), as well as uses the new instrument's AutoVibrato (also wrong).