[Bug/Linux] SoundFonts directory handling, log spam when not detected

[SeongGino]

A two-piece issue, both stemming from the same problem. TFE loads SoundFonts at a hardcoded directory, $HOME/SoundFonts, which might produce home folder clutter for users. Perhaps we should be using $XDG_DATA_HOME/TheForceEngine/SoundFonts (i.e. ~/.local/share) as we're already using for the configuration files and other user data?

This folder is not made by TFE, but creating one does allow SF2 soundfonts to work as expected - but again, not ideal to dump unneeded folders in the home dir.

---

On a related note, if TFE doesn't detect this folder, as soon as the audio engine is booted (and "SF2 Synthesized MIDI" is selected as the currently active Midi device), the log is spammed with:

...
[Error : readDirectory] opendir(/home/user/SoundFonts/) failed with 2

[Error : readDirectory] opendir(/home/user/SoundFonts/) failed with 2

[Error : readDirectory] opendir(/home/user/SoundFonts/) failed with 2

[Error : readDirectory] opendir(/home/user/SoundFonts/) failed with 2
...

(Posted a log file for demonstration: 1.6mb large for sitting at the title screen for maybe all of six seconds. Ouch.)

[mlauss2]

Yes, the same issue as #309

[mlauss2]

Please give PR #343 a try

[SeongGino]

The log spam seems to have been resolved and TFE is reading most of the data files from /usr/share/TheForceEngine. I also put a mod zip into ~/.local/share/TheForceEngine/Mods (had to make the mods folder) and it reads that fine.

I noticed though that the soundfonts only seem to be read from the /usr/share directory now, which is read only on virtually all Linux distros. Is this intentional? For normal use, this is fine, but that does mean using custom SF2s would be more difficult (or at least require root access, which may be seen as needless if a user just wants a different soundfont and rather not deal with system MIDI).

[mlauss2]

Oh, you want it to look at ~/.local/share/TFE/SoundFonts/ as well ? Looking at multiple paths is currently not supported, simply because the windows build doesn't need that. I'll ponder a solution, but cannot promise anything (yet).

[mlauss2]

if you want please try PR #355