View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001570||OpenMPT||Playback Compatibility||public||2022-02-18 04:05||2022-02-19 13:58|
|Reporter||Lachesis||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.30.02.00 / libopenmpt 0.6.1 (upgrade first)|
|Summary||0001570: IT sustain loop released into loop with current position after loop should not always modulo the position.|
This issue refers to the behavior tested by SusAfterLoop.it: when a sustain loop is released into the sample loop, usually the sample position is moved into the loop.
However, in IT when both loops are bidirectional and the sustain loop is currently reversed and the position is past the end of the normal loop, sustain release seems to not modify the position and the sample plays normally in reverse until it reaches the loop.
|Steps To Reproduce|
Play the attached module with IT: the sample continues in reverse until just before the cut, where the saw loop briefly plays.
Play the attached module with OpenMPT: the saw loop immediately plays after sustain release.
Play the attached module with libxmp: it crashes, which is the only reason I found this �♀️
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||Yes (OpenMPT 1.30.01)|
|Tested code revision (in case you know it)|
sus_after_loop_bidi_to_bidi.it.zip (524 bytes)
I was using the GUS driver for some reason! The SB16 driver and WAV writer behave identically.
Yes, I should note I've been testing with the SB16 driver, where this behavior does occur. Sorry, I'll clarify that in future reports.
It's strange the GUS driver is the one that doesn't do this since that's seems like the one where this would make the most sense.
Yeah, I normally use the SB16 driver as well for testing (it's the most sensible one) - but for some reason, this time when testing the module IT decided to auto-detected the GUS in my DOSBox setup rather than the SB16! Strange...
All the software-mixed drivers share the same loop processing code, so they behave the same typically, but the GUS naturally needs its own loop handling, and I would expect that not too much attention was spent on matching the edge cases between the drivers.
I'm afraid this might be rather tricky to fix - the playback engine currently doesn't allow playing past the end of whatever is currently defined to be the sample loop - among other things, the loop wrap-around buffer would need to be bypassed until we have actually entered the sample loop. at least some of the loop point handling would have to be moved from the player (
|2022-02-18 04:05||Lachesis||New Issue|
|2022-02-18 04:05||Lachesis||File Added: sus_after_loop_bidi_to_bidi.it.zip|
|2022-02-18 10:18||Saga Musix||Assigned To||=> Saga Musix|
|2022-02-18 10:18||Saga Musix||Status||new => assigned|
|2022-02-18 20:35||Saga Musix||Note Added: 0005100|
|2022-02-18 20:38||Saga Musix||Note Edited: 0005100|
|2022-02-19 01:04||Lachesis||Note Added: 0005104|
|2022-02-19 10:46||Saga Musix||Note Added: 0005107|
|2022-02-19 13:58||Saga Musix||Note Added: 0005110|