Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
eekee opened this issue Mar 29, 2019 · 12 comments · Fixed by #7620
Closed

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

eekee opened this issue Mar 29, 2019 · 12 comments · Fixed by #7620

Comments

@eekee
Copy link

@eekee eekee commented Mar 29, 2019

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

This comment has been minimized.

Copy link
Member

@PeterN PeterN commented Mar 29, 2019

What operating system/MIDI driver are you using?

@eekee

This comment has been minimized.

Copy link
Author

@eekee eekee commented Mar 30, 2019

Windows 10/default of binary installation.

@EgyLynx

This comment has been minimized.

Copy link

@EgyLynx EgyLynx commented Apr 2, 2019

Are that happened also 1.9.0?

@nielsmh

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Apr 2, 2019

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

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Apr 2, 2019

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

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Apr 2, 2019

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

This comment has been minimized.

Copy link
Author

@eekee eekee commented Apr 3, 2019

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

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Apr 3, 2019

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

This comment has been minimized.

Copy link
Author

@eekee eekee commented Apr 3, 2019

Strange! Well, thanks for looking at it.

@James103

This comment has been minimized.

Copy link
Contributor

@James103 James103 commented Jul 4, 2019

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

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Jul 4, 2019

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

@nielsmh

This comment has been minimized.

Copy link
Contributor

@nielsmh nielsmh commented Jul 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.