What operating system/MIDI driver are you using?

Windows 10/default of binary installation.

Are that happened also 1.9.0?

There were definitely some tunes in OpenMSX that set registered parameters in bad ways which bled over to other tunes, the major example was the pitch bend range. That's being handled in the music drivers (both Win32 and DMusic) to reset those parameters before every tune. I'm trying to reproduce this now but so far not having any luck.

Maybe I should find/write some tool to determine what controllers, RPN/NRPN, and possibly even SysEx, those various sets use.

Okay now I managed to reproduce it, with Scott Joplin Anthology's title melody (The Entertainer) losing one or more channels. I'm not yet sure which tune caused it, but I have some debugging code in now that logs which controllers and parameters are being touched. (I only ever see anything touch RPN 0, which is being reset every time.)

I'm not finding which particular tune is causing it (since it may also depend on how far into it has been played), but I think the safest bet would be to make MidiFile objects keep track of which controllers/parameters need to be reset after playback, so the synth/output can get a sequence to do that at the end. (Resetting everything every time can be very slow, so it's best to construct a minimal reset sequence.)

Makes sense, but just to check, when you say "resetting everything", do you mean just sending the one Reset All Controllers message? I'm finding it a bit hard to believe there's no way to normalize everything quickly for the next song, on a 21st century computer.

I checked the MIDI data being sent, via MIDI-OX, and it should be sending both All Notes Off and Reset All Controllers messages on every channel between every song. I don't understand why "reset all controllers" does not in fact reset all controllers on any of the synths I have tried.

Strange! Well, thanks for looking at it.

I was gonna post this as a new issue, but looking through, I found this would be a good place to put it.

Version of OpenTTD

• OpenTTD: 20190603-master-g846fc8fe09
• OS: Windows 7 32-bit
• Music driver: "dmusic"

Expected result

The full song with all of its notes should still be played, even after several hours of flipping through tracks and music sets.

Actual result

After a few hours of flipping through and playing tracks and changing the music set several times, the "dmusic" driver will stop playing certain MIDI note channels, meaning that you will get less and less notes until eventually the driver stops playing MIDI music at all.

Steps to reproduce

• Flip through tracks very quickly by repeatedly clicking on the "previous track" / "next track" buttons.
• Change music sets by clicking on the "Change set" dropdown and selecting a new music set.
• Wait several hours while the tracks are being played one after another as expected, changing music sets periodically.

I'll try to reproduce and possibly include a fix in #7620

@James103
I've re-read the DMusic driver code a bit, and I don't see any obvious reason why it could begin misbehaving like that. The driver code itself uses REFERENCE_TIME like the DMusic API does, and REFERENCE_TIME values can represent more than 256 million hours before there is any risk of overflow.
I assume you're using the MS softsynth (the default if you don't specify a port in the driver configuration), and how that works is unknown.
The symptoms you describe sound almost like floating point loss of precision, and I wonder if it could be something in Microsoft's synthesizer code that breaks, and might require restarting the synth once in a while.