Removed the HTML from the report. (HTML shows up in the preview, but not in the actual bug report. Who knew?)

How OpenMPT displays parameters to the user does not influence at all how the plugin will sound. 800 per mille is exactly the sem as 80 per cent, and you will see that OpenMPT in fact shows both values in the plugin editor (80% is the value as the plugin reports it, 800‰ is the unit OpenMPT internally uses for mapping a 0...1000 range to the internal 0...1 range used by plugins).

The real problem here isn't the dry/wet ratio, but rather that the channels to which the plugin is applied to are surround channels, and it seems like OpenMPT's implementation of the Flanger plugin is not 100% identical to the old DMO plugin that is being emulated here. The left and right channel cancel each other out so you only get silence in the "wet" signal. I'll have to see which part of the Flanger plugin emulation is broken but it's unlikely to be the Dry/Wet value itself.

HTML shows up in the preview, but not in the actual bug report. Who knew?

That's a bug in MantisBT that still hasn't fixed sadly, there are certain HTML elements that should be allowed but do not work when MarkDown is enabled. Use MarkDown for formatting instead.

So yeah, when I implemented the Chorus and Flanger replacement plugins, I thought that they do exactly the same thing except for a few differences in their parameters. Turns out that the Chorus effect has a mono buffer for the delayed signal (which just adds left and right together => this results in silence for surround channels!), while the Flanger effect has a stereo buffer. However, I implemented both Chorus and Flanger with the mono buffer, not noticing the slight difference in the output (I didn't test the output with stereo samples, oops).

Well, I'm glad I'm not losing my mind after all, heh heh. It's interesting that the problem wasn't what I thought it was, too! I didn't notice those channels in that module were Surround instead of Center/Mono. Switching them to anything other than Surround does, indeed, result in the audio sounding like it should. I'm glad I started using libopenmpt for Impulse Tracker files, now. This seems important (but not urgent nor high priority).

I kind of worry, though… I wonder how many people have made modules using these exact settings and, if the settings are fixed in a future version, will it have a backlash? In short: I wonder if would be better to just go "this is how it works, now" than it would be to make it work how it was intended to?

Thank you for looking into this! And, of course, thank you all for maintaining such a great project for so many years!

I kind of worry, though… I wonder how many people have made modules using these exact settings and, if the settings are fixed in a future version, will it have a backlash? In short: I wonder if would be better to just go "this is how it works, now" than it would be to make it work how it was intended to?

If the difference between the old and new implementation turns out to be bigger than just "doesn't work as intended with surround channels", there will be some sort of migration path to make newly created files sound as they previously did. "Newly" in this case means any modules made with OpenMPT 1.27-1.29 and using the Flanger plugin. For those, the migration path will most likely be simple: Automatically replace the Flanger plugin with the Chorus plugin upon loading the file and adjust a few parameters.

This is fixed as of r15377 (OpenMPT 1.30.00.46). Test builds can be obtained from https://builds.openmpt.org/builds/ (may take an hour or two to show up).

For modules made with OpenMPT 1.27-1.29, a compatible legacy plugin is provided that does not show up in the plugin manager by default (those songs will use it automatically). With the new implementation, Flanger behaves like the original DMO plugin.

This bugfix will not be backported to OpenMPT 1.29 / libopenmpt 0.5 most likely and only be available in OpenMPT 1.30 / libopenmpt 0.6 onwards.

I can confirm that both OpenMPT 1.30.00.46 (r15378 and r15383) and xmp-openmpt 0.6.0 pre-13 (r15379 and r15383) correctly play the outdated module as intended. I did not, however, personally test the interim versions. (r15377 seems to be missing from the build downloads, in fact…) In my tests, however, I did find a rather strange problem.

Using the example module, I attempted to make a new FX… thing for Channels 15 and 16. In the newer builds of OpenMPT, there was a difference between the existing "Flang" effect and the new "Flanger" effect I made despite using the exact same settings. It's subtle, but it's easily heard if one channel is set to "Flang" while the other is set to "Flanger".<br>(I've attached the modified module to save you two minutes' time.) I'm not sure if this is intentional or not since the two plugins are supposed to be more-or-less identical aside from their Surround Channel compatibility, but I figured it was worth mentioning.

I cannot spot any differences here. Note that if you added the plugin while the module was playing and didn't completely stop and restart playback afterwards, it is very well possible that the two plugin instances will be sounding slightly different because they will be out of phase. But after stopping playback, they should be in phase again. Is this maybe what you observed?

Note that if you added the plugin while the module was playing and didn't completely stop and restart playback afterwards, it is very well possible that the two plugin instances will be sounding slightly different because they will be out of phase.

Freakin' heck, I'm dumb. Yes, that was the exact problem. Oddly enough, though, after reloading the program and the module, it doesn't go out-of-phase even during play. Ugh.

I'm just gonna hush up and say "Problem solved, thank you for your hard work!" now. Heh heh.

Freakin' heck, I'm dumb. Yes, that was the exact problem. Oddly enough, though, after reloading the program and the module, it doesn't go out-of-phase even during play. Ugh.

Yes, because then the two plugins will be running for exactly the same amount of time (it doesn't matter if a note is playing or not). I'll consider this issue to be resolved then. :)