View Issue Details

IDProjectCategoryView StatusLast Update
0001570OpenMPTPlayback Compatibilitypublic2022-02-19 13:58
ReporterLachesis Assigned ToSaga Musix  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Platformx64OSWindowsOS Version10
Product VersionOpenMPT 1.30.02.00 / libopenmpt 0.6.1 (upgrade first) 
Summary0001570: IT sustain loop released into loop with current position after loop should not always modulo the position.
Description

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 �‍♀️

TagsNo tags attached.
Has the bug occurred in previous versions?Yes (OpenMPT 1.30.01)
Tested code revision (in case you know it)

Activities

Lachesis

Lachesis

2022-02-18 04:05

reporter  

Saga Musix

Saga Musix

2022-02-18 20:35

administrator   ~0005100

Last edited: 2022-02-18 20:38

Sadly it seems like there is one of those rare discrepancies between what the WAV writer and the SB16 sound driver does - the SB16 driver is identical to OpenMPT's behaviour, as far as I can see.

I was using the GUS driver for some reason! The SB16 driver and WAV writer behave identically.

Lachesis

Lachesis

2022-02-19 01:04

reporter   ~0005104

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.

Saga Musix

Saga Musix

2022-02-19 10:46

administrator   ~0005107

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.

Saga Musix

Saga Musix

2022-02-19 13:58

administrator   ~0005110

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 (CSoundFile::KeyOff) to the mixer (Fastmix.cpp).

Issue History

Date Modified Username Field Change
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