OpenMPT Wiki - Recent changes [en]

Development: Foreign Bugs

Saga Musix — Tue, 28 Jul 2026 17:15:18 GMT

← Older revision		Revision as of 17:15, 28 July 2026
Line 7:		Line 7:
	\|-		\|-
	! Project !! Status !! affects !! Description !! Link		! Project !! Status !! affects !! Description !! Link
			\|-
			\| Windows 11 MIDI Service \|\| open \|\| OpenMPT \|\| MidiSrv's lazy-loading causes music applications to hang on first use \|\| https://github.com/microsoft/MIDI/issues/1076
	\|-		\|-
	\| cross-platform-actions \|\| open \|\| libopenmpt \|\| Cleaner orthogonal API \|\| https://github.com/cross-platform-actions/action/discussions/150		\| cross-platform-actions \|\| open \|\| libopenmpt \|\| Cleaner orthogonal API \|\| https://github.com/cross-platform-actions/action/discussions/150

Development: Foreign Bugs

Manx — Fri, 17 Jul 2026 15:38:59 GMT

Foreign Bugs

← Older revision		Revision as of 15:38, 17 July 2026
Line 9:		Line 9:
	\|-		\|-
	\| cross-platform-actions \|\| open \|\| libopenmpt \|\| Cleaner orthogonal API \|\| https://github.com/cross-platform-actions/action/discussions/150		\| cross-platform-actions \|\| open \|\| libopenmpt \|\| Cleaner orthogonal API \|\| https://github.com/cross-platform-actions/action/discussions/150
	\|-
	\| MSVC \|\| open \|\| OpenMPT \|\| LNK4279 warning when building ARM64EC projects with VS2026 18.6.0 Compiler 19.51 \|\| https://developercommunity.visualstudio.com/t/LNK4279-warning-when-building-ARM64EC-pr/11090020 https://developercommunity.visualstudio.com/t/LNK4279-icall-thunk-mismatch-on-ARM64EC-/11087716#T-N11092812
	\|-		\|-
	\| Vorbis \|\| open \|\| OpenMPT \|\| Fix typos in tonal masking curve level adjustments \|\|https://gitlab.xiph.org/xiph/vorbis/-/merge_requests/41		\| Vorbis \|\| open \|\| OpenMPT \|\| Fix typos in tonal masking curve level adjustments \|\|https://gitlab.xiph.org/xiph/vorbis/-/merge_requests/41
Line 92:		Line 90:
	\| --- \|\| --- \|\| --- \|\| --- \|\| ---		\| --- \|\| --- \|\| --- \|\| --- \|\| ---
	\|-		\|-
	\| GCC \|\| pending 2025-12-09 \|\| libopenmpt \|\| x86: Inefficient code generation with -m3dnow -msse since GCC 12 \|\| https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121230		\| MSVC \|\| pending 2026-07-14 \|\| OpenMPT \|\| LNK4279 warning when building ARM64EC projects with VS2026 18.6.0 Compiler 19.51 \|\| https://developercommunity.visualstudio.com/t/LNK4279-warning-when-building-ARM64EC-pr/11090020 https://developercommunity.visualstudio.com/t/LNK4279-icall-thunk-mismatch-on-ARM64EC-/11087716#T-N11092812
			\|-
			\| GCC \|\| pending 2025-12-09 \|\| libopenmpt \|\| x86: Inefficient code generation with -m3dnow -msse since GCC 12 \|\| https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121230
	\|-		\|-
	\| FLAC \|\| pending 2025-06-13 (1.5.1) \|\| OpenMPT/openmpt123 \|\| Add C11 threads.h implementation in addition to pthread implementation for multithreaded encoding. \|\| https://github.com/xiph/flac/pull/822		\| FLAC \|\| pending 2025-06-13 (1.5.1) \|\| OpenMPT/openmpt123 \|\| Add C11 threads.h implementation in addition to pthread implementation for multithreaded encoding. \|\| https://github.com/xiph/flac/pull/822

Development: Test Cases/XM

Saga Musix — Wed, 15 Jul 2026 17:15:20 GMT

← Older revision		Revision as of 17:15, 15 July 2026
Line 21:		Line 21:

	{{Testcase\|format=xm\|name=ArpSlide.xm\|pass=4556}}		{{Testcase\|format=xm\|name=ArpSlide.xm\|pass=4556}}
	Like in some other trackers (e.g. Impulse Tracker), arpeggio notes are supposed to be relative to the current note frequency, i.e. the arpeggio should still sound as intended after executing a portamento. However, this is not quite as simple as in Impulse Tracker, since the base note is first rounded (up or down) to the ~~neares~~ semitone and then the arpeggiated note is added.		Like in some other trackers (e.g. Impulse Tracker), arpeggio notes are supposed to be relative to the current note frequency, i.e. the arpeggio should still sound as intended after executing a portamento. However, this is not quite as simple as in Impulse Tracker, since the base note is first rounded (up or down) to the nearest semitone and then the arpeggiated note is added.

	{{Testcase\|format=xm\|name=AutoVibratoSweepKeyOff.xm\|pass=21859}}		{{Testcase\|format=xm\|name=AutoVibratoSweepKeyOff.xm\|pass=21859}}

Development: Test Cases/IT

Saga Musix — Wed, 15 Jul 2026 17:14:04 GMT

Template:Testsuite Introduction

Saga Musix — Wed, 15 Jul 2026 17:11:20 GMT

← Older revision		Revision as of 17:11, 15 July 2026
Line 2:		Line 2:
	This test suite is a collection of {{{format}}} modules that were created while discovering playback bugs in OpenMPT. It is meant to be an easy way to check for regressions when code is changed, or to verify your own player’s routines if you are concerned about playback compatibility. The tests are designed in a way so that it is easy to figure out if your player is working correctly. In most test cases, your own player’s output can be heard on the left channel, while {{{tracker}}}’s output is heard on the right channel. This way, it is easy to find out whether everything works as intended or if there are any discrepancies without having to read any long test descriptions. When it is impossible to do such a cross-verification, a more detailed description of the test can usually be found in the sample, instrument or comment text.		This test suite is a collection of {{{format}}} modules that were created while discovering playback bugs in OpenMPT. It is meant to be an easy way to check for regressions when code is changed, or to verify your own player’s routines if you are concerned about playback compatibility. The tests are designed in a way so that it is easy to figure out if your player is working correctly. In most test cases, your own player’s output can be heard on the left channel, while {{{tracker}}}’s output is heard on the right channel. This way, it is easy to find out whether everything works as intended or if there are any discrepancies without having to read any long test descriptions. When it is impossible to do such a cross-verification, a more detailed description of the test can usually be found in the sample, instrument or comment text.

	Some test cases mention that they should stay quiet when played correctly. This does not take different ramping algorithms into account (so there might me a small “pop” at the start of samples or when changing the volume), and it is generally expected that the test cases are rendered at a mix rate of 44100 Hz, as otherwise different calculations of channel playback speed and interpolation settings may cause small but ~~noticable~~ differences in playback.		Some test cases mention that they should stay quiet when played correctly. This does not take different ramping algorithms into account (so there might me a small “pop” at the start of samples or when changing the volume), and it is generally expected that the test cases are rendered at a mix rate of 44100 Hz, as otherwise different calculations of channel playback speed and interpolation settings may cause small but noticeable differences in playback.

	Bit-exact output is not the goal of this test suite, correct playback is, so slight deviations from {{{tracker}}}’s output (e.g. different resampling algorithms, pop reduction, etc.) are acceptable. Some tests will only sound correct on the first run. Unless stated otherwise, it is not important that the test output sounds identical when looping the module.		Bit-exact output is not the goal of this test suite, correct playback is, so slight deviations from {{{tracker}}}’s output (e.g. different resampling algorithms, pop reduction, etc.) are acceptable. Some tests will only sound correct on the first run. Unless stated otherwise, it is not important that the test output sounds identical when looping the module.

← Older revision		Revision as of 17:14, 15 July 2026
Line 35:		Line 35:

	{{Testcase\|format=it\|name=DoubleSlide.it\|pass=21807}}		{{Testcase\|format=it\|name=DoubleSlide.it\|pass=21807}}
	Impulse Tracker generally initializes effect parameters, effect working memory and similar stuff once per row, before the effects actually run. When using (tone) portamento commands ~~simulatenously~~ in the effect column and volume column, this can lead to surprising results, and in order to emulate them correctly, it is crucial to implement the effect memory initialization in the exact same order as Impulse Tracker does:		Impulse Tracker generally initializes effect parameters, effect working memory and similar stuff once per row, before the effects actually run. When using (tone) portamento commands simultaneously in the effect column and volume column, this can lead to surprising results, and in order to emulate them correctly, it is crucial to implement the effect memory initialization in the exact same order as Impulse Tracker does:

	# Evaluate effect column Gxx parameter		# Evaluate effect column Gxx parameter
Line 83:		Line 83:

	{{Testcase\|format=it\|name=FilterEnvReset.it\|pass=1132}}		{{Testcase\|format=it\|name=FilterEnvReset.it\|pass=1132}}
	A cutoff value of 0 should not be reset to full cutoff when triggering a note just because the filter envelope is enabled. This bug is probably very specific to OpenMPT, because it gets rid of some ~~unneccessary~~ code.		A cutoff value of 0 should not be reset to full cutoff when triggering a note just because the filter envelope is enabled. This bug is probably very specific to OpenMPT, because it gets rid of some unnecessary code.

	{{Testcase\|format=it\|name=FilterPortaSmpChange.it\|pass=18417}}		{{Testcase\|format=it\|name=FilterPortaSmpChange.it\|pass=18417}}
Line 98:		Line 98:

	{{Testcase\|format=it\|name=filter-reset-carry.it\|pass=1165}}		{{Testcase\|format=it\|name=filter-reset-carry.it\|pass=1165}}
	I think this is also just an ~~extenion~~ to the previous test case, to make sure that it does not break anything else.		I think this is also just an extension to the previous test case, to make sure that it does not break anything else.

	{{Testcase\|format=it\|name=filter-reset-envelope.it\|pass=16016}}		{{Testcase\|format=it\|name=filter-reset-envelope.it\|pass=16016}}
Line 188:		Line 188:
	Since the start row of a pattern loop is not reset on pattern transitions, it is possible to use a loop start past the end of the current pattern when using a pattern loop without explicit start command (SB0). In this case, playback should continue in the next pattern. In the example, this happens because the loop start is set to one row after the loop end after properly terminating the loop in pattern 0.		Since the start row of a pattern loop is not reset on pattern transitions, it is possible to use a loop start past the end of the current pattern when using a pattern loop without explicit start command (SB0). In this case, playback should continue in the next pattern. In the example, this happens because the loop start is set to one row after the loop end after properly terminating the loop in pattern 0.

	{{Testcase\|format=it\|name=LxxWith0Portamento-Amiga.it\|pass=~~r22552~~}}		{{Testcase\|format=it\|name=LxxWith0Portamento-Amiga.it\|pass=22552}}
	A strange edge case when using Lxx (Volume Slide + Tone Portamento) while the tone portamento effect memory is 0: The tone portamento ~~comamnd~~ is not initialized properly in this case, causing it always to assume that it's trying to execute a portamento down. If the current note is below the note to which the tone portamento would lead, this causes the note to immediately jump to the target note. If the current note is above the target note, nothing happens.		A strange edge case when using Lxx (Volume Slide + Tone Portamento) while the tone portamento effect memory is 0: The tone portamento command is not initialized properly in this case, causing it always to assume that it's trying to execute a portamento down. If the current note is below the note to which the tone portamento would lead, this causes the note to immediately jump to the target note. If the current note is above the target note, nothing happens.

	{{Testcase\|format=it\|name=LxxWith0Portamento-Linear.it\|pass=~~r22552~~}}		{{Testcase\|format=it\|name=LxxWith0Portamento-Linear.it\|pass=22552}}
	Same as [[#LxxWith0Portamento-Amiga.it\|LxxWith0Portamento-Amiga.it]], but with linear slides. The difference is that when the current note is above the target note, the frequency is decremented by 1 Hz on every tick (linear slides always slide by at least 1 Hz).		Same as [[#LxxWith0Portamento-Amiga.it\|LxxWith0Portamento-Amiga.it]], but with linear slides. The difference is that when the current note is above the target note, the frequency is decremented by 1 Hz on every tick (linear slides always slide by at least 1 Hz).

Line 262:		Line 262:

	{{Testcase\|format=it\|name=PitchPanReset.it\|pass=15870}}		{{Testcase\|format=it\|name=PitchPanReset.it\|pass=15870}}
	Pitch/Pan Separation can be ~~overriden~~ by panning commands, and should not be affected by Note Off or Note Fade notes.		Pitch/Pan Separation can be overridden by panning commands, and should not be affected by Note Off or Note Fade notes.

	{{Testcase\|format=it\|name=PortaCutCompat.it\|pass=9139}}		{{Testcase\|format=it\|name=PortaCutCompat.it\|pass=9139}}