Closed bryc closed 3 years ago
What I've gathered so far from this is that when speed is set to 0 and there are notes on the same row, the replayer keeps trying to retrigger note on each tick.
Try the following in hvl_play_irq(). On first if branch, add a check for ht_Tempo.
if(ht->ht_Tempo > 0 && ht->ht_StepWaitFrames <= 0 )
See if it breaks any other tunes.
@pachuco Nice, that seems to fix the issue (at least in my JS AHX player - can't figure out compilers for the life of me).
I'm not knowledgeable enough to say whether it breaks anything (my uneducated guess is that it doesn't).
Does the change affect all rows with F00
, or only the rows with F00
that have non-zero Note/Instrument data?
If the second, it narrows down the testing to only 7 out of 1289 AHX files:
Well, row data after the row that did F00 is not gonna matter, because it never gets reached.
Upon reaching such row, that branch of hvl_play_irq() would get endlessly retriggered on each tick/IRQ. The branch itself calls hvl_process_step() for each voice.
Done differently in commit. Coincides with AHX.
The AHX file in question: https://modland.ziphoid.com/pub/modules/AHX/Yelm/oldskoolcrackintrosong.ahx
It plays for about a minute, then on the last pattern, there is a slight pause before a final deep decaying chord/crescendo, which plays seemingly infinitely (speed is set to
F00
). It sounds correct on AHX under Amiga, however, HivelyTracker outputs a loud buzz sound instead. This bug carries over to the XMPlay plugin as well, where it's held for an additional 1 minute of play time before moving to the next track. Foobar2000 solves this issue by skipping the infinite ending altogether (but not relevant to hively itself).It appears to be some AHX quirk, because something similar occurs in bartman/abyss's JS player.