MIDI Mysteries
by crts from LinuxQuestions.org on (#5FN8W)
First, I am aware that MIDI is probably not of interest for most people. I have noticed, however, that the few people that still use it may have experienced problems with MIDI playback which seemed to work or break randomly.
I recently experienced some random behaviour while updating one of my SlackBuilds and traced the issue back to SDL2_mixer which is available on SBo. So this thread will focus on issues with SDL2_mixer, MIDI playback in particular. I did not find any documentation that specifically addresses the problems I witnessed and the documentation on the homepage seems to be out of date. So if anyone has some links that further illuminate the workings and configuration of SDL2_mixer, please post them in this thread.
One possible cause for MIDIs not playing in applications is that the optional dependencies for SDL2_mixer must be installed before one builds SDL2_mixer. If, e.g., you installed SDL2_mixer without its optional fluidsynth dependency and you install fluidsynth a few months later, then you may have forgotten that fluidsynth is an optional dependency of SDL2_mixer. Thus, your application will not be able to play MIDIs via fluidsynth unless you rebuild and reinstall SDL2_mixer. If you rebuild SDL2_mixer as part of an update it may seem that your application "magically" started working because some package was out of date before.
Another source of confusion is that SDL2_mixer comes with its own version of timidity. Unfortunately, the version of timidity that ships with SDL2_mixer has some incompatibilities with other packages on SBo. Here is a simplified description of how timidity works. It looks for its configuration file /etc/timidity/timidity.cfg. This may be an actual file or a link to another configuration file. If that file is a valid timidity configuration then MIDI will work. If timidity.cfg is missing then it will look for /etc/timidity/freepats.cfg. If freepats.cfg is valid then MIDI will also work. So the following two scenarios will work:
Code:# scenario a (crude.cfg is part of freepats)
# midi plays because timidity.cfg is present
/etc/timidity/crude.cfg
/etc/timidity/freepats.cfg
/etc/timidity/timidity.cfg -> /etc/timidity/crude.cfg
# scenario b
# midi plays because freepats.cfg is present
/etc/timidity/crude.cfg
/etc/timidity/freepats.cfgIf you replace freepats with, e.g., eawpats then you will have to create a link to eawpats.cfg
Code:# scenario c
# midi does not play because timidity.cfg and freepats.cfg are missing
/etc/timidity/eawpats.cfg
# this fixes the issue
ln -s /etc/timitdity/eawpats.cfg /etc/timitdity/timidity.cfgHowever, eawpats uses a few commands that are not understood by timidity, e.g., the "map" command. In my tests, the MIDIs still played fine, but you may run into issues eventually.
Another package from SBo that does not play nice with SDL2_mixer is TiMidity++. If you have TiMidity++ installed then this is what /etc/timidity/timidity.cfg looks like:
Code:$ cat /etc/timidity/timidity.cfg
...
trysource /etc/timidity/crude.cfg
trysource /etc/timidity/freepats.cfg
trysource /etc/timidity/eawpats.cfg
trysource /etc/timidity/fluid.cfgTimidity does not understand "trysource" and MIDI playback via SDL2_mixer will not work. There are two ways to resolve that conflict. You can create a link to a valid configuration that timidity can read in /usr/share/timidity, e.g.
Code:# mkdir /usr/share/timidity
# ln -s /etc/timidity/freepats.cfg /usr/share/timidity/timidity.cfgThe directory /usr/share/timidity is also searched for a timidity.cfg file and it takes precedence over /etc/timidity. So timidity will find the valid file /usr/share/timidity/timidity.cfg before it encounters the invalid file in /etc/timidity.
Alternatively you can try to resolve the conflict by installing fluidsynth and rebuild SDL2_mixer. This also fixed the MIDI issue for me.
The documentation also hints that SDL2_mixer can access a hardware MIDI device directly. I was not able to research that because I do not have a hardware MIDI device. If anyone wants to experiment with this then I would be interested in the results.
I further encountered some issues when TiMidity++ was used as ALSA sequencer client
Code:# sh /etc/rc.d/rc.timidity startbut I have not been able to reproduce those consistently. Nonetheless, it seems like a good idea to keep the SDL2_mixer/TiMidity++ incompatibility issue in the back of the mind when encountering problems with MIDI playback.
I hope, the above hints will be of help for people who still play with MIDIs every once in a while and also do not appreciate if things start working "magically" somehow. This usually means that things may just as well break "magically", with little chances to pinpoint and fix the root cause of the problem.
I recently experienced some random behaviour while updating one of my SlackBuilds and traced the issue back to SDL2_mixer which is available on SBo. So this thread will focus on issues with SDL2_mixer, MIDI playback in particular. I did not find any documentation that specifically addresses the problems I witnessed and the documentation on the homepage seems to be out of date. So if anyone has some links that further illuminate the workings and configuration of SDL2_mixer, please post them in this thread.
One possible cause for MIDIs not playing in applications is that the optional dependencies for SDL2_mixer must be installed before one builds SDL2_mixer. If, e.g., you installed SDL2_mixer without its optional fluidsynth dependency and you install fluidsynth a few months later, then you may have forgotten that fluidsynth is an optional dependency of SDL2_mixer. Thus, your application will not be able to play MIDIs via fluidsynth unless you rebuild and reinstall SDL2_mixer. If you rebuild SDL2_mixer as part of an update it may seem that your application "magically" started working because some package was out of date before.
Another source of confusion is that SDL2_mixer comes with its own version of timidity. Unfortunately, the version of timidity that ships with SDL2_mixer has some incompatibilities with other packages on SBo. Here is a simplified description of how timidity works. It looks for its configuration file /etc/timidity/timidity.cfg. This may be an actual file or a link to another configuration file. If that file is a valid timidity configuration then MIDI will work. If timidity.cfg is missing then it will look for /etc/timidity/freepats.cfg. If freepats.cfg is valid then MIDI will also work. So the following two scenarios will work:
Code:# scenario a (crude.cfg is part of freepats)
# midi plays because timidity.cfg is present
/etc/timidity/crude.cfg
/etc/timidity/freepats.cfg
/etc/timidity/timidity.cfg -> /etc/timidity/crude.cfg
# scenario b
# midi plays because freepats.cfg is present
/etc/timidity/crude.cfg
/etc/timidity/freepats.cfgIf you replace freepats with, e.g., eawpats then you will have to create a link to eawpats.cfg
Code:# scenario c
# midi does not play because timidity.cfg and freepats.cfg are missing
/etc/timidity/eawpats.cfg
# this fixes the issue
ln -s /etc/timitdity/eawpats.cfg /etc/timitdity/timidity.cfgHowever, eawpats uses a few commands that are not understood by timidity, e.g., the "map" command. In my tests, the MIDIs still played fine, but you may run into issues eventually.
Another package from SBo that does not play nice with SDL2_mixer is TiMidity++. If you have TiMidity++ installed then this is what /etc/timidity/timidity.cfg looks like:
Code:$ cat /etc/timidity/timidity.cfg
...
trysource /etc/timidity/crude.cfg
trysource /etc/timidity/freepats.cfg
trysource /etc/timidity/eawpats.cfg
trysource /etc/timidity/fluid.cfgTimidity does not understand "trysource" and MIDI playback via SDL2_mixer will not work. There are two ways to resolve that conflict. You can create a link to a valid configuration that timidity can read in /usr/share/timidity, e.g.
Code:# mkdir /usr/share/timidity
# ln -s /etc/timidity/freepats.cfg /usr/share/timidity/timidity.cfgThe directory /usr/share/timidity is also searched for a timidity.cfg file and it takes precedence over /etc/timidity. So timidity will find the valid file /usr/share/timidity/timidity.cfg before it encounters the invalid file in /etc/timidity.
Alternatively you can try to resolve the conflict by installing fluidsynth and rebuild SDL2_mixer. This also fixed the MIDI issue for me.
The documentation also hints that SDL2_mixer can access a hardware MIDI device directly. I was not able to research that because I do not have a hardware MIDI device. If anyone wants to experiment with this then I would be interested in the results.
I further encountered some issues when TiMidity++ was used as ALSA sequencer client
Code:# sh /etc/rc.d/rc.timidity startbut I have not been able to reproduce those consistently. Nonetheless, it seems like a good idea to keep the SDL2_mixer/TiMidity++ incompatibility issue in the back of the mind when encountering problems with MIDI playback.
I hope, the above hints will be of help for people who still play with MIDIs every once in a while and also do not appreciate if things start working "magically" somehow. This usually means that things may just as well break "magically", with little chances to pinpoint and fix the root cause of the problem.