Music sets (including DOS music) broken after trying other music sets

[eekee]

Version of OpenTTD

1.9.0RC1

Expected result

Each music set should play back as its author intended, regardless of sample volume set by other music sets.

Actual result

Sample volumes from one music set affect later sets chosen, or perhaps some samples are disabled. If unfamiliar with the music in question, noticeable effects include odd gaps and a strange 'sparseness' which sounds like one-finger playing.

Steps to reproduce

• Data files copied from DOS TTD CD-ROM, including music
• Get various music sets from Bananas (full list below)
• Load game
• Open Jukebox
• Turn off Shuffle
• Open Music Programme
• Use the Change Set button to change music set
• Play
• Skip some tracks
• Stop
• Repeat last 4 steps (from Change Set)

List of sets:

Only marking "affected" when I'm sure. It's hard to be sure without being familiar with each set, which would take me a long time.

• original_dos -- Affected
• [OpenMSX -- not tested]
• Holiday Island -- Affected, especially track 04 which has nothing but rhythm. Probably also track 01
• Modern Motion
• Radio Monochrome Volume 1.
• Scott Joplin Anthology -- Probably affected; I used to be familiar with Scott Joplin's music and I'm sure it wasn't this sparse.

[PeterN]

What operating system/MIDI driver are you using?

[eekee]

Windows 10/default of binary installation.

[EgyLynx]

Are that happened also 1.9.0?

[nielsmh]

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.

[nielsmh]

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.)

[nielsmh]

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.)

[eekee]

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.

[nielsmh]

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.

[eekee]

Strange! Well, thanks for looking at it.

[James103]

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.

[nielsmh]

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

[nielsmh]

@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.