Look for soundfonts by default in /usr/share/sounds/sf2

[Jacalz]

FluidSynth version

1.1.11

Current behavior

Nowadays it looks like we need to load files like /usr/share/sounds/sf2/GeneralUser.sf2 which is a bit annoying and it makes the need to write the full path every time.

Expected behavior

It would be way beter to have it look for sound fonts in /usr/share/sounds/sf2 by default so you only need to load the soundfont with GeneralUser.sf2 instead. This would make lide a lot easier 😄

From sudo fluidsynth -a alsa -s -g 1.5 /usr/share/sounds/sf2/GeneralUser.sf2
to sudo fluidsynth -a alsa -s -g 1.5 GeneralUser.sf2

[derselbst]

fluidsynth automatically loads the soundfont specified by synth.default-soundfont if none is provided via command line. The value of this setting is configurable at compile time. Type

info synth.default-soundfont

in the fluid shell to see its default value. Once configured you just type

fluidsynth -a alsa -s -g 1.5

Also, I recommend to avoid using sudo.

[Jacalz]

I am using the version from the Solus repo so a default at compile time is not an option. When not using Sudo it complains about not being able to set thread priority. Is that an issue with the Solus package?

[Jacalz]

And the default setting mean that you only can use one file. Having it automatically look for .sf2 files in that directory would make it easy to use multiple files...

[derselbst]

a default at compile time is not an option

Use a symlink?

When not using Sudo it complains about not being able to set thread priority.

Setup /etc/security/limits.conf or a similar config file in that folder to your needs.

Having automatically look for .sf2 files in that directory would make it easy to use multiple files...

I'm not convinced that we need this. And implementing this raises a couple of question:

• How to implement the default path (env. variable, dirname(synth.default-soundfont), custom path)?
• Compile-time or run-time configurable?
• How to deal with other OSs?
• How to deal with files that exist in this default directory as well as in the current working directory?
• After all: Why not writing a simple shell script for your use-case?

If you insist on your idea, I suggest you bring it to the mailing list for discussion.

[Jacalz]

I am really not that experienced with Linux to create a symlink and other tuff, I would guess that more people are the same.

I think that it would be best to have it as a compile time selectable variable so you could select a path on Windows and Mac also. Only
Looking for .sf2 files would be best.

Yes of course I could write a shell script but I think that this would make it easier for more users. I had been writing some documentation for Solus on this. That is why I want to make fluidsynth easier for more users to enjoy this great software:

getsolus/help-center-docs#180

[derselbst]

sudo mv 'GeneralUser GS 1.471'/'GeneralUser GS v1.471.sf2' /usr/share/sounds/sf2/GeneralUser.sf2

Your efforts in all honor, but why making documentation unnecessarily complicated? Soundfonts are specific to a certain user. You should collect them somewhere in your $HOME. Then you don't have to fiddle with the path.

And again: Don't use sudo unless you really need it. You can just ignore the thread priority issue.

Also: The guy is called S. Christian Collins

I think that it would be best to have it as a compile time selectable variable

For implementation details: mailing list, please. However, given your previous statement of "mak[ing] fluidsynth easier for more users to enjoy" I think this would be the most user unfriendly option, esp. because you already said "a default at compile time is not an option".

[Jacalz]

Okay thank you for the tips on my documentation, I will make sure to improve it 🙂👍

I was unclear with what I exactly meant but I still think this is kind of good idea. Maybe not in /usr/share/sounds/sf2 but in Home like you say. Will see about contacting the mailing list sometime in the future. Might rethink my idea in to something more useful. I am happy to learn more and help out. Thanks for having this conversation 🙂

You don't need /usr/share/sounds when /usr/share/soundfonts already exist. The default soundfont is just a symlink. However, if this feature is considered I think the following would be reasonable:

• Keep the default soundfont configurable at compile-time, since maintainers are already used to this, so no need to change it
• Allow soundfonts to be found at runtime with configurable paths. For example. look in the current directory and if it's not found, look at /usr/share/soundfonts next or $XDG (example, ~/.local/share/soundfonts). You would need the Windows/Mac equivalents too

I'd be happy to write a PR.

[Jacalz]

Thanks @remyabel 👍

[e-dervieux]

Hum, this look like the PR was closed without merging and so that this issue is still present. I cannot but strongly agree with @Jacalz that setting a soundfont at compile time seems to be a terrible idea IMHO:

1. the vast majority of users out there do not compile their software but either download pre-compiled binaries or use external tools that may handle the compilation for them (e.g. homebrew, aptitude, etc.). Also even if the user cares to compile fluidsynth, they may not be willing to change compilation flags / makefiles just to change a soundfont, which leads us to
2. it would seem desirable to be able to change the soundfont that you use at any time without having to recompile your software each time you do so. This is quite common practice as it allows one to quickly change between soundfonts which may very well have quite different sound renditions.

Regarding implementation details, this is indeed not trivial since apparently fluidsynth aims at being cross-platform. For UNIX-like OSs, I would have argued something simple like looking both in the default share/soundfonts folder and ~/.fluidsynth/soundfonts folder, prioritizing the user home's folder over the system-wide share folder if identical soundfont names exist, defaulting to default.sf2. Something similar may be implemented on Windows or MacOS though... An environment variable may also be quite relevant like a SF_PATH variable for instance, telling fluidsynth where to search.

Overall, it would be really nice to be able to call fluidsynth on a MIDI file like this, either:

fluidsynth soundfont_in_user_or_system_wide_searching_path.sf2 my_MIDI_file.midi

or

fluidsynth soundfont/in/a/specific/path.sf2 my_MIDI_file.midi

I'd be glad to see this PR live again.

[derselbst]

1. The package maintainer is responsible for setting a reasonable default soundfont for your OS / distribution. If it's not set, contact you package maintainer.
2. Every user is free to override the default soundfont setting by using a configuration file.
3. I'll will not be the one to revive the soundfont search path PR. As I said in the PR: Post to the mailing list and see if there's any feedback on this topic. Then revive the PR and we'll shape it together.

[e-dervieux]

@derselbst thanks for the info!

1. Will do. The homebrew formula, at least, is very much missing such a default sf2 file. EDIT: done, see here.
2. I did overlook this, sorry, thanks for letting me know! Still a bit painful because you're just chosing a single soundfont (see above remark about sound rendition).
3. I'm a bit uneased by mailing lists, although not as ranty as these guys, and I get the points of the "pro mailing list" camp. However, I find it quite dirty to have both a mailing list AND a GitHub, onto which people discard stuff / close PR and tell others to go on the mailing list. I sincerely don't get it (no sarcasm meant). I mean, why not close GitHub issues (or the possibility to open PR for instance), if we're forced to use the mailing list in all cases? Anyway, I might submit this to the mailing if I find some time...

[derselbst]

Due to fluidsynth's history, we still have many users subscribed to the mailing list. Even though I do recognize that the community has gained a stronger shift towards Github compared to 2018, I do not want to leave down the community on the mailing list. Also from my experience I believe that - for this particular topic - one might be more likely to get feedback from the mailing list guys, rather than from the Github discussion community. Feel free to prove me wrong. However, if you find that "quite dirty" I can't help you, sry.

What matters for me as a maintainer is that people don't just braindump their ideas and wishes here without ever having brought a new feature up for discussion or feedback. That's also what our contributing guides said back then (and still does today). We're all just volunteers and none of us wants to spend their spare time on something that isn't desired or isn't needed by anybody else. The linked PR is a good example of how it should not work: "Here's a PR, take it or leave it!" All I asked for 7 years ago was to write a short mail like "Hey guys, I want to do [...] here's a draft implementation [...] What do you think of it?" - But instead, the author closed the PR, so did the thread opener shortly afterwards. If the authors don't have an interest in seeing this feature implemented, why should I implement it for them?

Note that the questions I asked back then still remain unanswered. And because an almost 7yo closed issue is not the right place to discuss about this either, I will be locking this issue now.