View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001597||OpenMPT||Audio I/O||public||2022-05-15 13:16||2022-05-17 17:38|
|Reporter||RepellantMold||Assigned To||Saga Musix|
|Product Version||OpenMPT 1.30.04.00 / libopenmpt 0.6.3 (upgrade first)|
|Target Version||OpenMPT 1.30.05.00 / libopenmpt 0.6.4 (current stable)||Fixed in Version||OpenMPT 1.30.05.00 / libopenmpt 0.6.4 (current stable)|
|Summary||0001597: Bidi loops cutting off on a module I'm working on|
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.
|Steps To Reproduce|
Same bug happens with sustained loops.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?||Unsure|
|Tested code revision (in case you know it)||17322|
testcase.7z (342,219 bytes)
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.
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.
Fixed in r17346.
|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)|