Player: Not All Tracks Playing in Midi Files

[Chriees]

---

Name of the game: Mondschein

Player platform:

Raspberry Pi 3 B+
Retropie
Easy RPG Player

Describe the issue in detail and how to reproduce it:

I just started one of my favorite RPG Maker games and found out that not all midi tracks are playing. I checked the midi file on my pc and it appears to be complete, just on the retropie easy rpg player it only play one or two tracks. Like in the opening scene the midi files consists of 20 tracks or so, i can only hear 2 playing at the same time.

[carstene1ns]

Hoi, thanks for your bug report!
In default configuration we use an internal midi sequencer (fmmidi) as fallback, which sounds "electronic".
Can you try installing a soundfont for timidity or using wildmidi (if available)?

[Chriees]

Thanks a lot for your fast response and excuse me for my late answer. Since i am a beginner concerning raspberry pi, i dont really know how to do what you asked for.
The music doesnt sound electronic, it just sounds as if some instrument tracks rlare missing. The rest sounds fine.
How do i install a soundfont or use wildmidi? Is there any further info that you need?

[fmatthew5876]

I see this behavior on Ubuntu when I install timidity. When Installed, wildmidi selects some timidity configuration by default and then the midis barely work anymore. Only a few channels of sound are played.

When timidity is not installed, it uses something else (I think fluidsynth?). Then the midis play better.

[carstene1ns]

@fmatthew5876 Yes, you need to configure wildmidi manually, because it does not ship a patchset on it's own. We have some fallback logic to find timidity configuration when there is none available. However, wildmidi should support most of the features timidity has, but cannot use soundfonts.
You can see the used configuration file in the logfile. Can you provide the broken timidity configuration?

[fmatthew5876]

So I get this on the console in Player:

Debug: WildMidi: Using `/etc/timidity/timidity.cfg` as configuration file...

My timidity.cfg looks like this, it's the default one installed by Ubuntu 18.04 package.

# Instrument configuration file for timidity
# $Id: timidity.cfg,v 1.7 2005/09/03 19:26:03 hmh Exp $

# You can change just about every option in TiMidity++ using
# This config file.  Please refer to the timidity.cfg(5) manpage
# for more details

## If you have a slow CPU, uncomment these:
#opt EFresamp=d         #disable resampling
#opt EFvlpf=d           #disable VLPF
#opt EFreverb=d         #disable reverb
#opt EFchorus=d         #disable chorus
#opt EFdelay=d          #disable delay
#opt anti-alias=d       #disable sample anti-aliasing
#opt EWPVSETOZ          #disable all Midi Controls
#opt p32a               #default to 32 voices with auto reduction
#opt s32kHz             #default sample frequency to 32kHz
#opt fast-decay         #fast decay notes

## If you have a moderate CPU, try these:
#opt EFresamp=l
#opt EFreverb=g,42
#opt EFchorus=s
#opt s32kHz
#opt p64a

# Disabling some of the Midi Controls can help with the CPU usage a lot.
# The same goes to the VLPF, sample anti-aliasing and effects such as
# reverb and chorus

# By default, try to use the instrument patches from freepats:
source /etc/timidity/freepats.cfg

# alternatively, you can use the fluid-soundfont:
#source /etc/timidity/fluidr3_gm.cfg
#source /etc/timidity/fluidr3_gs.cfg

Switching from freepats.cfg to one of the other options it behaves like it did when timidity wasn't installed.

Having to configure stuff like this on Linux is sort of ok (You always ending up having to configure s* on linux anyway..). Having to do it on an android mobile device is pretty much a show stopper. Someone downloads EasyRPG from the appstore, audio is broken. They just forget it and move, possibly leaving a bad review.

I'm trying to wrap my head about the midi situation.

What benefit do we get from wildmidi? Why not timidity or fluidsynth directly? I understand fluidsynth has an annoying glib dependency, but I would think quality and consistency in audio is more important than build system problems.

[fdelapena]

Concerning the bug report, Freepats has been incomplete during years on most GNU/Linux distributions due to the uncertain license of some instruments. This means it lacks some required instruments to be a full GM set. Due to the lack of maintenance, some distributions started including a Fluid R3 .pat version, so this covers the long standing MIDI issue on them. In your case it seems you need to install Fluid R3 package, not provided by Freepats. Player packages for GNU/Linux could be improved to handle this, depend on Fluid R3 .pat packages where available and try reading the r3 cfg instead of setting this by hand by the user.

My two cents about some alternatives if FluidSynth is still not considered:

• There is a tool to convert .sf2 into Gravis UltraSound (.pat) spare samples + .cfg, but this might lose instrument information, however this is a way to get them supported by WildMIDI. Testing this scenario requires experimenting with SoundFonts and tools and may take some time/effort.
• The fluidlite approach as an alternative for a lightweight version without glib requires to parse .mid (SMF, standard MIDI file) by our own (we already have a SMF parser for the optional FMMIDI synth).

Whichever the synth we use, we need to consider three requirements:

• Handle the loopstart when the 111 event is set.
• Skip silence on MIDI start for some cases (there some notes by Sormat about this behavior).
• Get MIDI ticks properly, there is an event command which gets this data and it is not dependent on seconds played, so it needs to be calculated properly. There is at least one popular game using a custom battle system based on music beats and keypresses.

In case of using a system-provided FluidSynth as a dynamic library dependency, we really need to make sure we may control how MIDI is provided. If FluidSynth exposes public API to control events we could use it as-is, otherwise we could use the SMF parser from FMMIDI code and send these events to the synth. The second approach allows to use FluidLite in other ports for a more lightweight package, but still may require some effort.

Additionally, we could make sure about the license of some small SoundFont available out there are able to be distributed on GNU/Linux distributions without licensing issues. The mentioned SF2 could be discussed on most strict distribution mailing lists, mainly Debian (strict DFSG guidelines) and Fedora (strict patent fear policies). There are also SF3, supported by FluidLite and very recent FluidSynth versions (vorbis compressed samples), but samples are still large and may require a lot of RAM on playback. Well, this point is not that critical, as GNU/Linux users are more used to the lack of 1:1 accurate compatibility and the large Fluid R3 is good enough for most distro needs ;).

[fmatthew5876]

So it turns out I didn't have the fluid gm and gs sound fonts actually installed.

So when it worked after commenting out freepats.cfg and selecting fluidr3_gs.cfg it's because it fell back to some default soundfont.

But now after installing fluid-soundfont-gs and fluid-soundfont-gm the midi audio stops working (with no error message) if I source one of their configs. I guess that's the lack of support for sf2 biting us.

So far just by installing packages I go from barely working midi, to working midi, to not working at all midi. Call it user error, but the user experience of having to deal with all this is pretty crap.

The other side of this is that game developers will test their games against specific soundfonts. Now the player has a different soundfont and gets an entirely different experience.

It will ease portability if we can find one library or set of libraries that works on all platforms the same way.

There are problems with the windows midi playback too: #1418. The new solution should be able to play the windows .dls soundfonts.

Additionally, we could make sure about the license of some small SoundFont available out there are able to be distributed on GNU/Linux distributions without licensing issues.

If we could find a decent soundfont with such permissive license that would be great. I image many of them could have problems though. Don't most of the popular ones have non-free package repos? Could EasyRPG player and the default EasyRPG soundfont could be separate packages on platforms where it's a problem?

The ideal would be to ship the windows soundfont for RPG_RT.exe compatibility, but I'm guessing the license probably doesn't allow that.

[fmatthew5876]

To continue this saga. As I mentioned installing those soundfonts made my midi sound completely stop working. Even commenting everything out of /etc/timidity.cfg nothing could get my midi sound to work again. The only thing that worked was deleting /etc/timidity.cfg and the finally it went back to wildmidi's default soundfont again.

My vote is for fluidsynth. glib or no glib.

[carstene1ns]

Closing as "User configuration issue". :wink: