View Issue Details

IDProjectCategoryView StatusLast Update
0001597OpenMPTAudio I/Opublic2022-05-17 17:38
ReporterRepellantMold Assigned ToSaga Musix  
PrioritynoneSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version11
Product VersionOpenMPT 1.30.04.00 / libopenmpt 0.6.3 (upgrade first) 
Target VersionOpenMPT 1.30.05.00 / libopenmpt 0.6.4 (current stable)Fixed in VersionOpenMPT 1.30.05.00 / libopenmpt 0.6.4 (current stable) 
Summary0001597: Bidi loops cutting off on a module I'm working on
Description

I encountered this weird bug with a bidirectionally looped sample at certain sample lengths with a module I'm attempting to work on as a collaboration, no C frequency (up to 96000) loops back like it's supposed to and instead the sample just cuts off, every other key works.
Bizarrely, this samples plays on other modules but gets reproduced with my module so I'm not sure what's going on.

Steps To Reproduce
  1. Open up OpenMPT
  2. Play "testcase.mptm"
Additional Information

Same bug happens with sustained loops.

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

Activities

RepellantMold

RepellantMold

2022-05-15 13:16

reporter  

testcase.7z (342,219 bytes)
Saga Musix

Saga Musix

2022-05-15 18:17

administrator   ~0005178

That's an interesting edge case. Essentially it happens because, when the sample is about to reverse, its playback position is exactly at the end of the loop, which is normally relatively unlikely to happen but in this case it will happen for most C notes because the mixing rate (48000 Hz in your case) and sample rates will be exact multiples of each other, so the sample playback position will always be exactly at the loop end when it's about to reverse. If you set the mixing rate to 44100 Hz for example, this won't be the case because the sample position may be close to the loop end when it reverseds but not precisely. It also works if you load the sample into an older module because OpenMPT 1.30 has a new ping-pong loop handling system and sample positions will be slightly different when the playback quirk for emulating older OpenMPT versions is enabled.

RepellantMold

RepellantMold

2022-05-16 02:40

reporter   ~0005179

Interesting indeed.

Saga Musix

Saga Musix

2022-05-16 19:30

administrator   ~0005180

Until an update is available, you can also enable the playback compatibility setting "Do not repeat last sample point in ping pong loop, like IT’s software mixer". It will slightly alter bidi loop behaviour but the effect is mostly observable with chip samples, so not really relevant in this particular case.

Saga Musix

Saga Musix

2022-05-17 17:38

administrator   ~0005181

Fixed in r17346.

Issue History

Date Modified Username Field Change
2022-05-15 13:16 RepellantMold New Issue
2022-05-15 13:16 RepellantMold File Added: testcase.7z
2022-05-15 13:20 Saga Musix Assigned To => Saga Musix
2022-05-15 13:20 Saga Musix Status new => assigned
2022-05-15 18:17 Saga Musix Note Added: 0005178
2022-05-16 02:40 RepellantMold Note Added: 0005179
2022-05-16 19:30 Saga Musix Note Added: 0005180
2022-05-17 17:38 Saga Musix Note Added: 0005181
2022-05-17 17:38 Saga Musix Status assigned => resolved
2022-05-17 17:38 Saga Musix Resolution open => fixed
2022-05-17 17:38 Saga Musix Fixed in Version => OpenMPT 1.30.05.00 / libopenmpt 0.6.4 (current stable)
2022-05-17 17:38 Saga Musix Target Version => OpenMPT 1.30.05.00 / libopenmpt 0.6.4 (current stable)