FluidSynth / fluidsynth

Software synthesizer based on the SoundFont 2 specifications
https://www.fluidsynth.org
GNU Lesser General Public License v2.1
1.76k stars 246 forks source link

put a soundfont file in /usr/share/soundfonts/default.sf2 upon installing fluidsynth #1005

Open brandneetjan opened 2 years ago

brandneetjan commented 2 years ago

It seems that by default there is no default.sf2 file packaged with fluidsynth (pun intended ?). I had an issue with this today on my Artix Linux system and fixed it using this: https://wiki.archlinux.org/title/FluidSynth#SDL_Mixer. But I think it would be best and logical/expected to have an actual default.sf2 file coming with a fluidsynth installation. What do you guys think ? Or maybe your opinion is that this is the distro package maintainers responsibility ?

derselbst commented 2 years ago

default.sf2 is meant as a placeholder or pointer to a real soundfont. Primarily I see the user (or local sysadmin) in charge to put a symlink there and make it point to your preferred soundfont. Secondarily, this job could be done by a package maintainer, yes.

I vote against shipping a soundfont with "a fluidsynth installation" for the following reasons:

pedrolcl commented 2 years ago

This is in my opinion an entirely valid issue. Fluidsynth is not functional without a Soundfont. And there are messages complaining about a missing 'default.sf2' when another soundfont file is not provided. On the other hand, all of the reasons argued by Tom are equally valid, and I agree. We have discussed in another place that PREFIX/share/soundfonts (or PREFIX/share/sounds/sf2 in Debian-ish distros) is outside the scope of the application, and should be managed by the package maintainers only. In case we ship a soundfont file, the proper install place would be PREFIX/share/fluidsynth/.

But anyway, I can't strongly oppose to an "emergency soundfont" provided as a fallback when any other options are not available. Of course this should fulfill some requirements: to be small, free with a compatible license, and with enough quality to compellingly render some small SMF demos, preferably GM compatibles.

What other soft synths do? the popular and windows only VirtualMIDISynth does not ship any. On the other hand the Java's OpenJDK Gervill has an internally generated emergency soundbank.

clort81 commented 1 year ago

Every opportunity should be exploited to teach naive users that MIDI and also General-MIDI do not specify the exact (PCM) sound that is played, only in the case of general-MIDI,the type of sound desired. The obvious analogy of soundfonts should to text fonts should be explained to the kids maybe with a text like this: "Soundfonts are like text fonts, but for sounds. In the case of a text font, the application requests the letter 'A' to be drawn, but it looks different depending on the chosen font. Similarly the general-MIDI application might request an 'Oboe' sound, but that will sound different depenting on which soundfont the user prefers. People have their own individual preferences for fonts and often applications allow the user to select the preferred font. Likewise general-MIDI players give users the flexibility to choose their preferred 'font' for music."

baweaver commented 7 months ago

Having come across this in the future I must concur with the above opinions that this can be confusing for a new user, and would take at least a few searches to reasonably remedy.

In lieu of shipping with a default sound font would it be possible to consider a prompt or instructional guide rather than error messages like the following?:

fluidsynth: error: fluid_sfloader_load(): Failed to open '/usr/local/Cellar/fluid-synth/2.3.4/share/soundfonts/default.sf2': File does not exist.
fluidsynth: error: Unable to open file '/usr/local/Cellar/fluid-synth/2.3.4/share/soundfonts/default.sf2'
fluidsynth: error: Failed to load SoundFont "/usr/local/Cellar/fluid-synth/2.3.4/share/soundfonts/default.sf2"

I can appreciate the predicament of finding a free and reasonable soundfount as @pedrolcl has mentioned, but would continue to advocate for a knowledge sharing approach which redirects those who encounter it to further reading.

As someone who is very naive on MIDI and just got started in experimenting with it I find that there are a lot of areas to potentially get lost in across tools, so whatever we can do to address those gaps would be very appreciated. I'd love to put in a PR to help on this, but I also do not know a good resource to point folks to either at the moment.