ZDoom

Thank you for merging my fix.
After some further testing I discovered there was one more very minor and rarely occuring bug: Double-voice instruments randomly don't play the second voice. And fixed that as well!
Here's pull request: https://github.com/coelckers/gzdoom/pull/474 (just one-character change)

Once it gets merged and dev build is made, I can ask Csonicgo to do some thorough testing of OPL Synth. I hope we will have the same quality as before removal of MusLib. The behavior may be different when there are not enough voices (1-2 emulated chips), but as GZDoom supports emulation of up to 8 chips, we won't need to bother about that at all, I suppose.

Thanks for the fix. I hope someone with better knowledge of OPL can have a look at it and confirm that everything is ok.

Hooray, I attempted to fix this bug myself and here's the pull request:
https://github.com/coelckers/gzdoom/pull/471

As I already mentioned, all problems were in findFreeVoice() function after rewriting the code from MusLib to Chocolate Doom.
There were two separate issues which were causing different kind of problems:
1. General issue with note cutoffs: Algorithm to select a free voice was too simple and not appropriate. Changed to "least-recently-freed voice" algorithm. We need to prefer the least recently freed voice, as more recently freed voices can still play a tone from their release state.
2. Issue specific to particular songs (for example D_STALKS mentioned here): Some MIDIs use "Sustain Pedal" controller event, but for some reason (bug in the MIDI itself or MIDI player?) the sustain pedal is turned on permanently and never released. OPL voices then were getting into Sustained state and were blocked in this state forever - you could see all voices (star) in Orange color with "Stat Music". I improved the algorithm to preferentially release voices in sustained states when there are no free voices. Now D_STALKS sounds much better.

I'm bumping this because I have a clue what might be the cause of note cutoff issues.

Basically there's difference between old (MUSLIB's) "findFreeChannel" function and the new (Chocolate Doom's ?) "findFreeVoice" function logic.
It seems that the old function "findFreeChannel" was trying to some sort of magic like "give me the least recently used OPL voice", but the new function "findFreeVoice" is just very simple and gives the first OPL voice which is marked "free". And that does not work well.
The OPL voice is marked free, once there's a "note off" event. However after note off, the OPL voice is entering "Release" state, which is still playing a sound (it's fading off). And when there is adjacent note just after the previous note, the "note on" event tries to find first free OPL voice, and it finds the same voice as previous note was playing on, and breaks the previous note's release state - that's the audible note cut-off.
I think you will need to re-implement the logic of "findFreeChannel" function to fix this.
Not sure if it's the only problem, there can be more, but I'm trying to direct you. I would really appreciate if you try to fix this, because OPL Synth emulator is the key feature in GZDoom for me.
I created some MIDI files for analysis of this problem. I can provide the MIDI examples and more information if it will help you.
Thank you!

Csonicgo wrote:I hate to bump this with more bad news, but D_STALKS in BTSX Ep 2 is unlistenable after 30-40 seconds in - with stat music all the asterisks turn yellow and nothing will play save for a few clipped notes.

Yup, that's exactly the bug I was pointing out and demonstrating on page 1. It sounds as if what Graf wants is a trimmed-down version of the song that omits all sound channels that are not affected by the cutoff, and removes the first 20-some seconds so that the glitch occurs immediately instead of after 20 seconds of silence.

I hate to bump this with more bad news, but D_STALKS in BTSX Ep 2 is unlistenable after 30-40 seconds in - with stat music all the asterisks turn yellow and nothing will play save for a few clipped notes.

Woops, sorry. Here you go.

As I said before, I don't know if the bug will be reproduced since the file has been so drastically altered, but here you go.

Have you forgotten about this? With the data at hand I cannot do much here.

Okay, tomorrow. I don't have any more free time for modding today, sorry!

What I need is a version that shows the problem after a few seconds. The remix doesn't help me at all because the other voices are back in.

To explain, I need this to output debug messages during playback and having to wait several minutes each time for the error to occur essentially means I cannot debug it. It'd just take far too long to get somewhere and with all voices present I cannot even see what goes wrong.

Here's a remixed version of the original song... I have significantly lowered the volume of every channel except the faulty ones as demonstrated by Wildweasel.

The faulty channel starts playing at 0:24 and should disappear at 0:48.

EDIT: file removed

Graf: Yes the first few minutes of the song is silent, just like in the original composition. The disappearing ambient sound thingy that Wildweasel showed in his post only happens much later.

Guess you'll have to wait?

I can try cutting the song to immediately jump to that part, although I'm not sure if the bug will trigger if I shorten the song. I have a strong feeling that the bug won't happen if I cut the beginning of the song.

EDIT: I'll try lowering (a lot) the volume of all the non-offending channels instead of outright deleting them.

@Nash:

What am I supposed to hear? Your cut down version seems to be silent on all synths except Timidity++.

I hope I find some time to look at it today, last week I've been a bit busy.

Yeah I'm not saying it's wrong, it's valid songwriting, I do that a lot too. I doubt that's even the problem, it's probably something else. But that is precisely the location where the music stops so IDK.