[fluid-dev] Allow soundfonts to be searched from multiple directories

[Tom]

Per request I'm moving this discussion to the mailing list.

Motivation: https://github.com/FluidSynth/fluidsynth/issues/453
Current PR: https://github.com/FluidSynth/fluidsynth/pull/454

Essentially the feature would add an option called "synth.soundfont-dirs".
I've chosen to make this a semi-colon delimited list, like
"/usr/share/soundfonts/;~/.local/share/soundfonts" (on Windows, it's
"C:/soundfonts/"). When specifying soundfonts on the command-line, the new
functionality is to look for the soundfont in the current directory, and if
it's not there, search the other directories. This is so the user does not
need to specify an absolute path everytime.

Some of the concerns:

- How to implement the default path (env. variable,
dirname(synth.default-soundfont), custom path)?

IMO, the most intuitive place is to look in the current directory, then
look in locations determined by the filesystem hierarchy (FHS, XDG, etc;
and Windows equivalent). If we allow a run-time configurable option, the
user can rearrange the search path too.

- Compile-time or run-time configurable?

Allow it to be compile-time configurable for maintainers to set a
reasonable default, but also run-time configurable for user convenience.

- How to deal with other OSs?

See #1.

- How to deal with files that exist in this default directory as well as
in the current working directory?

See #1.

- After all: Why not writing a simple shell script for your use-case?

Reducing duplication of effort. I think this patch is simple enough that
the user convenience to dev implementation ratio is good enough.

[Marcus Weseloh]

Hi,

I like the general idea. In my opinion it only makes sense if there are
sensible default values for (nearly?) all platforms, so having a
compile-time option would be a prerequisite.

But I think requiring the user to set -O synth.soundfont-dirs=... on the
command-line if the compiled-in default needs to be changed doesn't go far
enough. As the motivation behind this is to make command-line usage easier
for users, maybe we should go one step further and provide a mechanism to
load a runtime default configuration for all settings. Similar to the
config-file mechanism, but something that takes effect before the synth
object is created and which has the same effect as specifying the switches
on the command-line. So on UNIX have a ~/.fluidsynthrc file, and possibly a
system wide /etc/fluidsynth.conf (Not sure how this translates to the
Windows world, though). In this file you could specify default settings but
still override them on the command-line.

Cheers,

Marcus

Post by Tom
Per request I'm moving this discussion to the mailing list.
Motivation: https://github.com/FluidSynth/fluidsynth/issues/453
Current PR: https://github.com/FluidSynth/fluidsynth/pull/454
Essentially the feature would add an option called "synth.soundfont-dirs".
I've chosen to make this a semi-colon delimited list, like
"/usr/share/soundfonts/;~/.local/share/soundfonts" (on Windows, it's
"C:/soundfonts/"). When specifying soundfonts on the command-line, the new
functionality is to look for the soundfont in the current directory, and if
it's not there, search the other directories. This is so the user does not
need to specify an absolute path everytime.
- How to implement the default path (env. variable,
dirname(synth.default-soundfont), custom path)?
IMO, the most intuitive place is to look in the current directory, then
look in locations determined by the filesystem hierarchy (FHS, XDG, etc;
and Windows equivalent). If we allow a run-time configurable option, the
user can rearrange the search path too.
- Compile-time or run-time configurable?
Allow it to be compile-time configurable for maintainers to set a
reasonable default, but also run-time configurable for user convenience.
- How to deal with other OSs?
See #1.
- How to deal with files that exist in this default directory as well
as in the current working directory?
See #1.
- After all: Why not writing a simple shell script for your use-case?
Reducing duplication of effort. I think this patch is simple enough that
the user convenience to dev implementation ratio is good enough.
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

[Carlo Bramini]

Hello,
if I can say my opinion, it would be better to leave that change outside the library.
It looks more a feature for the application that it is using FluidSynth.
This introduces also the need to distinguish between absolute/relative/virtual/network/etc paths, that can vary on different platforms. I doubt that just doing strcat() between the strings inside this "synth.soundfont-dirs" and the string written on the command line will be enough.

Although it may look useful for some typists, command auto-completation and command history of the shells give already a solution.

Sincerely.

Post by Tom
Per request I'm moving this discussion to the mailing list.
Motivation: https://github.com/FluidSynth/fluidsynth/issues/453
Current PR: https://github.com/FluidSynth/fluidsynth/pull/454
Essentially the feature would add an option called " synth.soundfont-dirs". I've chosen to make this a semi-colon delimited list, like "/usr/share/soundfonts/;~/.local/share/soundfonts" (on Windows, it's "C:/soundfonts/"). When specifying soundfonts on the command-line, the new functionality is to look for the soundfont in the current directory, and if it's not there, search the other directories. This is so the user does not need to specify an absolute path everytime.
* How to implement the default path (env. variable, dirname(synth.default-soundfont), custom path)?
IMO, the most intuitive place is to look in the current directory, then look in locations determined by the filesystem hierarchy (FHS, XDG, etc; and Windows equivalent). If we allow a run-time configurable option, the user can rearrange the search path too.
* Compile-time or run-time configurable?
Allow it to be compile-time configurable for maintainers to set a reasonable default, but also run-time configurable for user convenience.
* How to deal with other OSs?
See #1.
* How to deal with files that exist in this default directory as well as in the current working directory?
See #1.
* After all: Why not writing a simple shell script for your use-case?
Reducing duplication of effort. I think this patch is simple enough that the user convenience to dev implementation ratio is good enough.
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

[sqweek E.]

I had similar thoughts, re. searching the file system path not being a synth feature. But simply deferring to the application has other downsides when it comes to soundfont adoption in general - end users must manually configure each application and there’s no standard way to do this. Eg. for my application I chose to dodge this configuration and bundle a soundfont, which removes burden from less technical users but also means users who already have sound fonts installed need to download 100mb instead of 10mb.

Fluidsynth is probably in a good position to be able to define conventions like standard search paths and/or configuration files - it would be great if the result could be adopted by other soundfont based software?

-sqweek

Post by Carlo Bramini
Hello,
if I can say my opinion, it would be better to leave that change outside the library.
It looks more a feature for the application that it is using FluidSynth.
This introduces also the need to distinguish between absolute/relative/virtual/network/etc paths, that can vary on different platforms. I doubt that just doing strcat() between the strings inside this "synth.soundfont-dirs" and the string written on the command line will be enough.
Although it may look useful for some typists, command auto-completation and command history of the shells give already a solution.
Sincerely.

Post by Tom
Per request I'm moving this discussion to the mailing list.
Motivation: https://github.com/FluidSynth/fluidsynth/issues/453
Current PR: https://github.com/FluidSynth/fluidsynth/pull/454
Essentially the feature would add an option called " synth.soundfont-dirs". I've chosen to make this a semi-colon delimited list, like "/usr/share/soundfonts/;~/.local/share/soundfonts" (on Windows, it's "C:/soundfonts/"). When specifying soundfonts on the command-line, the new functionality is to look for the soundfont in the current directory, and if it's not there, search the other directories. This is so the user does not need to specify an absolute path everytime.
* How to implement the default path (env. variable, dirname(synth.default-soundfont), custom path)?
IMO, the most intuitive place is to look in the current directory, then look in locations determined by the filesystem hierarchy (FHS, XDG, etc; and Windows equivalent). If we allow a run-time configurable option, the user can rearrange the search path too.
* Compile-time or run-time configurable?
Allow it to be compile-time configurable for maintainers to set a reasonable default, but also run-time configurable for user convenience.
* How to deal with other OSs?
See #1.
* How to deal with files that exist in this default directory as well as in the current working directory?
See #1.
* After all: Why not writing a simple shell script for your use-case?
Reducing duplication of effort. I think this patch is simple enough that the user convenience to dev implementation ratio is good enough.
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

[Reinhold Hoffmann]

My optinion is that searching and organizing soundfont files are the task of
an application and NOT of fluidsynth. Our applications come with a standard
soundfont file but in addition with the feature that the user can load a
non-standard soundfont file based on own needs. Our applications also gather
where the soundfont file is located and that the user can easily switch
between different soundfont files. The biggest effort here is anyway the
user interface which is different for each app.

fluidsynth and the fluidsynth LGPL libraries are a clean focus to
synthesizer features where searching and organizing soundfont files is more
a data managing task rather a task of a synthesizer software.
(I also imagine that searching and organizing files is strongly dependant on
the platform e.g. Windows is different than Linux and macOS (access rights,
paths etc.)). My view, the energy of the open source input of smart people
should be towards the core value of a synthesizer which is unique where
organizing files is just a kind of "doing" without special skills.

Reinhold

-----Ursprüngliche Nachricht-----
Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=***@nongnu.org]
Im Auftrag von sqweek E.
Gesendet: Freitag, 2. November 2018 07:08
An: FluidSynth mailing list
Betreff: Re: [fluid-dev] Allow soundfonts to be searched from multiple
directories

I had similar thoughts, re. searching the file system path not being a synth
feature. But simply deferring to the application has other downsides when it
comes to soundfont adoption in general - end users must manually configure
each application and there’s no standard way to do this. Eg. for my
application I chose to dodge this configuration and bundle a soundfont,
which removes burden from less technical users but also means users who
already have sound fonts installed need to download 100mb instead of 10mb.

Fluidsynth is probably in a good position to be able to define conventions
like standard search paths and/or configuration files - it would be great if
the result could be adopted by other soundfont based software?

-sqweek

Post by Carlo Bramini
Hello,
if I can say my opinion, it would be better to leave that change outside the library.
It looks more a feature for the application that it is using FluidSynth.
This introduces also the need to distinguish between

absolute/relative/virtual/network/etc paths, that can vary on different
platforms. I doubt that just doing strcat() between the strings inside this
"synth.soundfont-dirs" and the string written on the command line will be
enough.

Post by Carlo Bramini
Although it may look useful for some typists, command auto-completation

and command history of the shells give already a solution.

Post by Carlo Bramini
Sincerely.

Post by Tom
Per request I'm moving this discussion to the mailing list.
Motivation: https://github.com/FluidSynth/fluidsynth/issues/453
Current PR: https://github.com/FluidSynth/fluidsynth/pull/454
Essentially the feature would add an option called "

synth.soundfont-dirs". I've chosen to make this a semi-colon delimited list,
like "/usr/share/soundfonts/;~/.local/share/soundfonts" (on Windows, it's
"C:/soundfonts/"). When specifying soundfonts on the command-line, the new
functionality is to look for the soundfont in the current directory, and if
it's not there, search the other directories. This is so the user does not
need to specify an absolute path everytime.

Post by Carlo Bramini

Post by Tom
* How to implement the default path (env. variable,

dirname(synth.default-soundfont), custom path)?

Post by Carlo Bramini

Post by Tom
IMO, the most intuitive place is to look in the current directory, then

look in locations determined by the filesystem hierarchy (FHS, XDG, etc; and
Windows equivalent). If we allow a run-time configurable option, the user
can rearrange the search path too.

Post by Carlo Bramini

Post by Tom
* Compile-time or run-time configurable?
Allow it to be compile-time configurable for maintainers to set a

reasonable default, but also run-time configurable for user convenience.

Post by Carlo Bramini

Post by Tom
* How to deal with other OSs?
See #1.
* How to deal with files that exist in this default directory as well

as in the current working directory?

Post by Carlo Bramini

Post by Tom
See #1.
* After all: Why not writing a simple shell script for your use-case?
Reducing duplication of effort. I think this patch is simple enough that

the user convenience to dev implementation ratio is good enough.

Post by Carlo Bramini

Post by Tom
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

[Marcus Weseloh]

Hi,

Am Do., 1. Nov. 2018 um 20:19 Uhr schrieb Carlo Bramini <

Post by Carlo Bramini
if I can say my opinion, it would be better to leave that change outside
the library. It looks more a feature for the application that it is using
FluidSynth.

I agree, this feature shouldn't be in the Fluidsynth library. But it would
be a nice feature for the fluidsynth executable that we ship (which uses
the library).

Cheers,

Marcus

[Tom M.]

Thanks for the feedback guys!

I share the concerns brought up here and agree that this is no suitable feature for the fluidsynth library. I.e. the current proposal to make it a FluidSetting and expose a find_soundfont() function via the API is not suitable.

IMO this should be implemented as exclusive feature for the executable. Preferably **not** as compile time option. A normal user who acutally benefits from this feature should not dependent on any compile flags a packager has or hasn't specified when compiling fluidsynth.

Keep in mind that synth.default-soundfont approaches a similar problem using a cmake flag. However I couldn't find any distribution (ubuntu, megeia, fedora, openSUSE) making use of this.

I propose to keep it simple and implement this using an environment variable: If a soundfont specified on the commandline isn't found in the current working directory, the fluidsynth exec. looks through the $PATH variable and takes the first one it finds. The user only needs to setup up this env. var. in his ~/.bash.rc or similar. Ofc. we could also use a custom env. variable. I like $PATH because it's convenient on *nix and Windows.

Also when implementing this, I suggest to remove synth.default-soundfont and possibly also the DEFAULT_SOUNDFONT cmake flag. After all, the current implementation only uses the default soundfont when the user plays back a MIDI file.

Tom

[Tom]

Hi, I'm happy to go along with what you said, but I have a few comments. If
we decide to read from an environment variable, we should read it from the
existing @***@. It doesn't make sense to use $PATH since
that has a different purpose on Linux systems (namely, searching for
binaries).

Further, the reason I made it compile-time configurable is two-fold:
consistency with existing code and to allow the maintainer to set a
reasonable default. If we're doing this to make it more convenient for
(potentially non-technical users), it's generally the maintainer's job to
adapt the search path to their system. The user shouldn't have to manually
edit the path themselves. Although, one approach is to have a global file
like /etc/fluidsynth.rc (filled by the maintainer) and then make the local
one (empty by default, filled by the user) take precedence.

Thanks for the feedback.

Post by Tom M.
Thanks for the feedback guys!
I share the concerns brought up here and agree that this is no suitable
feature for the fluidsynth library. I.e. the current proposal to make it a
FluidSetting and expose a find_soundfont() function via the API is not
suitable.
IMO this should be implemented as exclusive feature for the executable.
Preferably **not** as compile time option. A normal user who acutally
benefits from this feature should not dependent on any compile flags a
packager has or hasn't specified when compiling fluidsynth.
Keep in mind that synth.default-soundfont approaches a similar problem
using a cmake flag. However I couldn't find any distribution (ubuntu,
megeia, fedora, openSUSE) making use of this.
I propose to keep it simple and implement this using an environment
variable: If a soundfont specified on the commandline isn't found in the
current working directory, the fluidsynth exec. looks through the $PATH
variable and takes the first one it finds. The user only needs to setup up
this env. var. in his ~/.bash.rc or similar. Ofc. we could also use a
custom env. variable. I like $PATH because it's convenient on *nix and
Windows.
Also when implementing this, I suggest to remove synth.default-soundfont
and possibly also the DEFAULT_SOUNDFONT cmake flag. After all, the current
implementation only uses the default soundfont when the user plays back a
MIDI file.
Tom
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

[Tom M.]

FLUID_DAEMON_ENV_FILE is a cmake variable, specifically one that points to a config file for running fluidsynth as global systemd service. This isn't suitable, I was referring to a shell environment variable.

to allow the maintainer to set a reasonable default

That's the point: A package maintainer doesn't have the knowledge to evaluate a "reasonable default". That's why it is not done, see DEFAULT_SOUNDFONT.

The user shouldn't have to manually edit the path themselves.

Of course he has to. Neither any maintainer nor fluidsynth are responsible for guessing how the user organizes his soundfont collection. Frankly, if the "potentially non-technical user" is too lazy to specify a proper path to the soundfont(s) he wants to use, I expect him to take the time and set up proper search paths *once*, because those are only suitable in his unique environment.


Tom

[Ceresa Jean-Jacques]

Hi,

For independence and maintainability reasons it's obvious that this feature should be addressed ONLY at application level and NEVER in the fluidsynth's library code.

However, as already said "it would be a nice feature for the fluidsynth executable that we ship". Also being aware of different file searching paradigm within different OS, we also could think this feature (if implemented) should be selectable/removable at cmake time.

jjc.

 

Message du 01/11/18 20:19
De : "Carlo Bramini"
A : "FluidSynth mailing list"
Objet : Re: [fluid-dev] Allow soundfonts to be searched from multiple directories
Hello,
if I can say my opinion, it would be better to leave that change outside the library.
It looks more a feature for the application that it is using FluidSynth.
This introduces also the need to distinguish between absolute/relative/virtual/network/etc paths, that can vary on different platforms. I doubt that just doing strcat() between the strings inside this "synth.soundfont-dirs" and the string written on the command line will be enough.
Although it may look useful for some typists, command auto-completation and command history of the shells give already a solution.
Sincerely.

Post by Tom
Per request I'm moving this discussion to the mailing list.
Motivation: https://github.com/FluidSynth/fluidsynth/issues/453
Current PR: https://github.com/FluidSynth/fluidsynth/pull/454
Essentially the feature would add an option called " synth.soundfont-dirs". I've chosen to make this a semi-colon delimited list, like "/usr/share/soundfonts/;~/.local/share/soundfonts" (on Windows, it's "C:/soundfonts/"). When specifying soundfonts on the command-line, the new functionality is to look for the soundfont in the current directory, and if it's not there, search the other directories. This is so the user does not need to specify an absolute path everytime.
* How to implement the default path (env. variable, dirname(synth.default-soundfont), custom path)?
IMO, the most intuitive place is to look in the current directory, then look in locations determined by the filesystem hierarchy (FHS, XDG, etc; and Windows equivalent). If we allow a run-time configurable option, the user can rearrange the search path too.
* Compile-time or run-time configurable?
Allow it to be compile-time configurable for maintainers to set a reasonable default, but also run-time configurable for user convenience.
* How to deal with other OSs?
See #1.
* How to deal with files that exist in this default directory as well as in the current working directory?
See #1.
* After all: Why not writing a simple shell script for your use-case?
Reducing duplication of effort. I think this patch is simple enough that the user convenience to dev implementation ratio is good enough.
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

[Ceresa Jean-Jacques]

Post by Tom M.

The user shouldn't have to manually edit the path themselves.

Of course he has to. Neither any maintainer nor fluidsynth are responsible for guessing how the user organizes his soundfont collection.

Yes organization soundfont is only the application need. As pointed by Sqweek E " ...there’s no standard way to do this..".

I don't think that fluidsynth package is the right place to define good conventions like standard search paths and/or configuration files.

Instead (as suggered by Sqweek E), the community of application end users should probably helps to do that. This should need time to collect those informations.

this should lead to a dedicaced llibrary with its API.

 

Post by Tom M.
Frankly, if the "potentially non-technical user" is too lazy to specify a proper path to the soundfont(s) he wants to use, I expect him to take the time and set up proper search paths *once*, because those are only suitable in his unique environment.

This is the minimum simple task that a end user should be able to do when this task is not frequent. Also using symbolic link should be useful.

jjc.

Post by Tom M.
Message du 03/11/18 06:16
De : "Tom M."
Objet : Re: [fluid-dev] Allow soundfonts to be searched from multiple directories
FLUID_DAEMON_ENV_FILE is a cmake variable, specifically one that points to a config file for running fluidsynth as global systemd service. This isn't suitable, I was referring to a shell environment variable.

to allow the maintainer to set a reasonable default

That's the point: A package maintainer doesn't have the knowledge to evaluate a "reasonable default". That's why it is not done, see DEFAULT_SOUNDFONT.

The user shouldn't have to manually edit the path themselves.

Of course he has to. Neither any maintainer nor fluidsynth are responsible for guessing how the user organizes his soundfont collection. Frankly, if the "potentially non-technical user" is too lazy to specify a proper path to the soundfont(s) he wants to use, I expect him to take the time and set up proper search paths *once*, because those are only suitable in his unique environment.
Tom
_______________________________________________
fluid-dev mailing list
https://lists.nongnu.org/mailman/listinfo/fluid-dev

[sqweek]

On Mon, 5 Nov 2018 at 23:59, Ceresa Jean-Jacques <

Post by Tom M.

Post by Tom M.

The user shouldn't have to manually edit the path themselves.

Of course he has to. Neither any maintainer nor fluidsynth are

responsible for guessing how the user organizes his soundfont collection.
Yes organization soundfont is only the application need. As pointed by
Sqweek E " ...there’s no standard way to do this..".
I don't think that fluidsynth package is the right place to define good
conventions like standard search paths and/or configuration files.
Instead (as suggered by Sqweek E), the community of application end users
should probably helps to do that. This should need time to collect those
informations.

Doing a quick survey of linux distros packaging FluidR3_GM.sf2, I see these
paths in use:

/usr/share/sounds/sf2/ (Debian, Ubuntu, CentOS)
/usr/share/soundfonts/ (Arch Linux, CentOS)

Yes CentOS uses both paths - but mainly the latter. I suspect its
/usr/share/sounds/sf2/default.sf2 is a symlink for compatibility.

There's no analogous way to survey paths in use on Windows/OSX that I'm
aware of. Looking on the application side, MuseScore has its own paths:

Windows: %HOMEPATH%\Documents\MuseScore2\Soundfonts
OSX/Linux: ~/Documents/MuseScore2/Soundfonts

A quick dive into LMMS source code suggests it behaves similarly,
defaulting to $DOCUMENTS/lmms/samples/soundfonts on all platforms.

I haven't looked into whether linux package maintainers for these apps have
tweaked them to look in the system paths, but either way I'm not seeing any
obvious conventions for other platforms. Perhaps of interest is that LMMS
on windows searches for VSTs in %PROGRAMFILES%\VstPlugins...

-sqweek

References:

https://www.archlinux.org/packages/community/any/soundfont-fluid/
https://packages.debian.org/sid/all/fluid-soundfont-gm/filelist
https://centos.pkgs.org/7/epel-x86_64/fluid-soundfont-gm-3.1-16.el7.noarch.rpm.html
https://packages.ubuntu.com/trusty/all/fluid-soundfont-gm/filelist
https://musescore.org/en/handbook/soundfonts-and-sfz-files#install
https://github.com/LMMS/lmms/blob/stable-1.2/src/core/ConfigManager.cpp

[Dan Eble]

For macOS, you might wish to survey Fink <http://www.finkproject.org/>, Homebrew <https://brew.sh/>, and MacPorts <https://www.macports.org/> packages.
—
Dan

[Reinhold Hoffmann]

On Windows there is no special folder for soundfonts. It is up to the
application.



We at Notation Software (www.notation.com <http://www.notation.com/> ) use



(a) the Windows' Public folder for those apps where Soundfonts can be
flexibly configurable.

"C:\Users\Public\Documents\Notation_3\Soundfonts"

(b) %PROGRAMFILES%\Notation_3\[app name] for those apps where only one fixed
soundfont can be used



The advantage of the Windows Public folder (similar to the Linux
distributions) vs. %HOMEPATH% is that all users of a PC can use it whereas
using %HOMEPATH% limits the usage just to one user who installed the
software.



That said, I vote for the fluidsynth app to do it in the same way and use

C:\Users\Public\Documents\fluidsnyth\Soundfonts.



Using

C:\Soundfonts is not a good idea due to Windows' admin rights policies.
%PROGRAMFILES% requires the installation on admin level and should only
being used for sondfonts for special apps.



My 2 cents...



Reinhold



_____

Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=***@nongnu.org]
Im Auftrag von sqweek
Gesendet: Samstag, 10. November 2018 07:39
An: jean-***@orange.fr; FluidSynth mailing list
Betreff: Re: [fluid-dev] Allow soundfonts to be searched from multiple
directories



On Mon, 5 Nov 2018 at 23:59, Ceresa Jean-Jacques

Post by Tom M.

The user shouldn't have to manually edit the path themselves.

Of course he has to. Neither any maintainer nor fluidsynth are responsible

for guessing how the user organizes his soundfont collection.

Yes organization soundfont is only the application need. As pointed by
Sqweek E " ...there's no standard way to do this..".

I don't think that fluidsynth package is the right place to define good
conventions like standard search paths and/or configuration files.

Instead (as suggered by Sqweek E), the community of application end users
should probably helps to do that. This should need time to collect those
informations.

Doing a quick survey of linux distros packaging FluidR3_GM.sf2, I see these
paths in use:

/usr/share/sounds/sf2/ (Debian, Ubuntu, CentOS)

/usr/share/soundfonts/ (Arch Linux, CentOS)

Yes CentOS uses both paths - but mainly the latter. I suspect its
/usr/share/sounds/sf2/default.sf2 is a symlink for compatibility.



There's no analogous way to survey paths in use on Windows/OSX that I'm
aware of. Looking on the application side, MuseScore has its own paths:



Windows: %HOMEPATH%\Documents\MuseScore2\Soundfonts

OSX/Linux: ~/Documents/MuseScore2/Soundfonts



A quick dive into LMMS source code suggests it behaves similarly, defaulting
to $DOCUMENTS/lmms/samples/soundfonts on all platforms.



I haven't looked into whether linux package maintainers for these apps have
tweaked them to look in the system paths, but either way I'm not seeing any
obvious conventions for other platforms. Perhaps of interest is that LMMS on
windows searches for VSTs in %PROGRAMFILES%\VstPlugins...



-sqweek



References:

https://www.archlinux.org/packages/community/any/soundfont-fluid/
https://packages.debian.org/sid/all/fluid-soundfont-gm/filelist
https://centos.pkgs.org/7/epel-x86_64/fluid-soundfont-gm-3.1-16.el7.noarch.r
pm.html
https://packages.ubuntu.com/trusty/all/fluid-soundfont-gm/filelist

https://musescore.org/en/handbook/soundfonts-and-sfz-files#install

https://github.com/LMMS/lmms/blob/stable-1.2/src/core/ConfigManager.cpp