View Issue Details

IDProjectCategoryView StatusLast Update
0001520OpenMPTPlayback Compatibilitypublic2021-12-04 18:45
Reporterkopper Assigned ToSaga Musix  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionopen 
Platformx64OSWindowsOS Version7
Product VersionOpenMPT 1.29.14.00 / libopenmpt 0.5.13 (upgrade first) 
Target VersionOpenMPT 1.29.15.00 / libopenmpt 0.5.14 (upgrade first)Fixed in VersionOpenMPT 1.29.15.00 / libopenmpt 0.5.14 (upgrade first) 
Summary0001520: F0F0007F not disableing resonant filter
Description

As of a recent update, setting a macro to F0F0007F is no longer deactivating the resonant filter. This has been working for me for ages and is now corrupting some SID-styled tunes I've made in the past. The added file is recreating the issue with my custom ZXX set built in. In a version prior to, I guess at least 1.26 the third tone would have sounded exactly as the first one, without any filter applied.

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

Activities

kopper

kopper

2021-11-22 11:50

reporter  

fltr.zip (1,399 bytes)
Saga Musix

Saga Musix

2021-11-22 12:03

administrator   ~0004916

The behaviour is correct: The filter is only supposed to be turned of if the cutoff is 127 and resonance is 0. That's how Impulse Tracker does but not how older versions of MPT did it. It has been the default behaviour since OpenMPT 1.20 for IT files. However, when importing songs made with older (Open)MPT versions, or when using the MPTM format, the legacy behaviour may be used instead. You can download older OpenMPT builds from https://download.openmpt.org/archive/openmpt/ (e.g. OpenMPT 1.23) and you will hear that they behave exactly the same on this specific file.

kopper

kopper

2021-11-23 05:44

reporter   ~0004922

This is weird, I swear the "wrong" sound has just happened with a recent version, not something from years ago.
Is there a simple solution to retain ZBF as my "reset" command then, combining it with a resonance command? Macros have always been a little black box for me and I was happy to have found this setup that did the job.

Saga Musix

Saga Musix

2021-11-23 09:27

administrator   ~0004923

This is weird, I swear the "wrong" sound has just happened with a recent version, not something from years ago.

That's possible if you were e.g. using an old song as a template, because OpenMPT will generally try to keep playing modules like the version the file was created with would play it.

Is there a simple solution to retain ZBF as my "reset" command then, combining it with a resonance command?

Yes, this should be helpful with manually crafting macros: https://wiki.openmpt.org/Manual:_Zxx_Macros

So to reset the filter resonance, append F0F00100 to your macro. Note that depending on the situation, it can also make more sense to set an instrument's default cutoff and resonance to 127 and 0 respectively. This is more compatible with some players that don't implement a fully macro interpreter (I think XMPlay is among those).

There is one more caveat though that you may not be aware of if you were using the legacy filter mode all the time: With IT-compatible filters it's impossible to turn off the filter for a playing note, and setting the resonance 0 if the cutoff is already at 127 doesn't do anything to the current note's filter (that's not a bug, just what IT is doing :). Only the next note played on that channel will play with the filter disabled.

kopper

kopper

2021-11-23 17:01

reporter   ~0004925

it's impossible to turn off the filter for a playing note

This seems to be the problem, I assume. I have used the F0F0007F macro to basically reset the filter on a new note, just as it was playing. Putting the macro with the added resonance command one row above does fix the issue, but that ofc means I have to change the modules. Is there a simple solution to get at least the playback to my "used" state? Like e.g. an older version of MPT or some compatibility settings? Thanks in advance.

Saga Musix

Saga Musix

2021-11-23 17:03

administrator   ~0004926

I really cannot recommend you turning off the compatibility flag when writing in IT format because OpenMPT will be the only player interpreting the module that way. Any other IT-compatible software will play it the way Impulse Tracker would. In the MPTM format however you are free to disable the Compatibility Setting "User IT’s filter coefficients (unless extended filter range is used) and behaviour". In fact, if you create a new MPTM file this setting is disabled by default, so maybe you were already working with MPTM files before when encountering the different behaviour?

kopper

kopper

2021-11-23 19:01

reporter   ~0004927

I was always using .it files ever since I've been started using MPT. That may have been the first bad choice to begin with. :D
The new behaviour on the C64-like tunes just recently catched my ear and I thought it was a version error, being fixed with the next release. To be honest, it would already be nice just to render the tunes the way I made them, for preservation (it's an old project I will never finish, hands down), so playback in other players is no big deal for me. So what would I need to do to recreate the sound I've been used to? The filter coefficient setting won't fix the issue for me, even after switching to a MPTM file. Again, the sheer probem seems to be the moment the macro comes in effect. On note play as in my original module or 1 row afterwards as it is now (and, apparently, the correct way IT would play it).

Saga Musix

Saga Musix

2021-11-23 20:15

administrator   ~0004928

If you think that a specific tune plays differently than it used to, please provide that tune (you can add a private note in case it's not supposed to be spread), because the example file provided definitely isn't affected by any recent changes. It's always possible that there's a bug that affects a "real" song, though, that isn't expressed by this particular example (as mentioned, I did verify that it plays exactly the same in older versions).

The filter coefficient setting won't fix the issue for me, even after switching to a MPTM file.

Just to make sure, you turned the setting off, correct? If the setting is turned off, it should absolutely behave the same with all OpenMPT versions because that code path should be essentially unmodified for the last ten years.

kopper

kopper

2021-11-23 21:42

reporter   ~0004929

Just to make sure, you turned the setting off, correct?
Yes, No change in sound whatsoever.
I've added one of the unfinished tracks in which the change was most noticable for me. The kick on channel 3 in the second pattern was playing unfiltered with my ZBF in a fairly recent version. Strangely, it is now playing unfiltered on the fourth beat and I really don't know why.

intro.zip (162,481 bytes)
Saga Musix

Saga Musix

2021-11-23 22:14

administrator   ~0004931

Thanks for the example file. This was introduced in r12932 / OpenMPT 1.29.02.00 as a side effect of fixing another edge case. Guess I'll have to find a more clever way to fix it... For the record, Impulse Tracker would also turn off the filter in your track.

Saga Musix

Saga Musix

2021-11-24 21:11

administrator   ~0004932

In fact, r12932 did break another already existing test case (really looking forward to that not happening anymore once 0001507 is in place...). r16016 now fixes both that test case and your module. Test builds will be available in a few hours from https://builds.openmpt.org/builds/ and of course the fix will be in the next stable OpenMPT version.

Issue History

Date Modified Username Field Change
2021-11-22 11:50 kopper New Issue
2021-11-22 11:50 kopper File Added: fltr.zip
2021-11-22 12:03 Saga Musix Note Added: 0004916
2021-11-23 05:44 kopper Note Added: 0004922
2021-11-23 09:27 Saga Musix Note Added: 0004923
2021-11-23 17:01 kopper Note Added: 0004925
2021-11-23 17:03 Saga Musix Note Added: 0004926
2021-11-23 19:01 kopper Note Added: 0004927
2021-11-23 20:15 Saga Musix Note Added: 0004928
2021-11-23 21:42 kopper Note Added: 0004929
2021-11-23 21:42 kopper File Added: intro.zip
2021-11-23 22:14 Saga Musix Note Added: 0004931
2021-11-23 22:14 Saga Musix Assigned To => Saga Musix
2021-11-23 22:14 Saga Musix Status new => assigned
2021-11-24 21:11 Saga Musix Note Added: 0004932
2021-11-24 21:13 Saga Musix Status assigned => resolved
2021-11-24 21:13 Saga Musix Fixed in Version => OpenMPT 1.30.01.00 / libopenmpt 0.6.0 (upgrade first)
2021-11-24 21:13 Saga Musix Target Version => OpenMPT 1.30.01.00 / libopenmpt 0.6.0 (upgrade first)
2021-12-04 18:45 Saga Musix Category Audio I/O => Playback Compatibility
2021-12-04 18:45 Saga Musix Fixed in Version OpenMPT 1.30.01.00 / libopenmpt 0.6.0 (upgrade first) => OpenMPT 1.29.15.00 / libopenmpt 0.5.14 (upgrade first)
2021-12-04 18:45 Saga Musix Target Version OpenMPT 1.30.01.00 / libopenmpt 0.6.0 (upgrade first) => OpenMPT 1.29.15.00 / libopenmpt 0.5.14 (upgrade first)