Enable sf3 extension

[tresf]

Upstream fluidsynth has added ogg encoded soundfont support. This won't be available until fluidsynth binaries are updated, so this should only be made available in the master branch for now.

Per #3286

[husamalhomsi]

After merging this, I think we should rename everything named SF2 to SF (in the GUI at least), for example SF2 directory to SF directory.

[Spekular]

At that point it might be worth extending to Soundfont. SF by itself doesn't say much to me.

…

On Oct 20, 2017 08:44, "Hussam Eddin Alhomsi" ***@***.***> wrote: After merging this, I think we should rename everything named SF2 to SF (in the GUI at least), for example SF2 directory to SF directory. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3895 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIgVmqFHjudXLSBu-h43pAMSj2mejQWGks5suEFXgaJpZM4P_s2O> .

[trebmuh]

Nice. I just did a build from GIT master + adding this patch, and using fluidsynth 1.1.8 .
Result is that I've been able to get sound from the "SF2 Player" when loading the FluidR3Mono_GM.sf3 file. Awesome and congratz @tresf !

Something I noticed is the name of the "SF2 Player" module which now could be misleading:

Shouldn't be renamed to "SF Player" or "SoundFont Player" as suggested by @Spekular (which is a clever suggestion I'd say)?

Another one is the logo on the module itself:

A third one is on the configuration window:

I suggest to add a "sf3 directory" or change the name to "soundfont directory". For information, the debian packagers has just started to separate into its own package the sf3 file from the musescore. This sf3 file is to be installed in /usr/share/sounds/sf3/ so it might have some sense to add a "sf3 directory" rather than using a common one for sf2 and sf3.

Hope that helps !

[tresf]

AFAIK, the sf2 folder is a relatively new addition and hasn't been made part of a stable release. This was carefully decided here: #1807. It's something we should be able to change if we can agree on something. We can even talk about an upgrade path for intermediary (RC) users although this may be overkill. I'd be a fan of samples/soundfonts personally. It's what I've been using myself for years.

From a naming perspective, I'm not sure sf2 is really that inaccurate or even bad. It's like making a folder called "MP3s" and having some M4A files in there.

Slightly off-topic... I have a vision forward that would encompass all bank files (sf2, sf3, sfz, sfArk, gig). This would strip any file format branding and replace it with a modularized, non-branded "instrument patch" instrument, which when moving towards a single-window design should be more future proof. The plugin could still be called sf2 under the covers, but from the surface the idea of a patch (... at least I propose..) should be agnostic to the user. They'd just drag it in like any other sample. </offtopic>.

[WrillicR]

@tresf, (to encourage your slightly off-topic vision) I've thought through that same concept, and I really like that you've thought of this too. I agree on having patch banks and samples together, it makes sense. As for sf3 files in LMMS, thanks, it will be appreciated.

[tresf]

So @LMMS/developers do we rename samples/sf2 to samples/soundfonts to be nomanclature-friend with the sf3 extension or do we leave it as-is?

If we change it, this decision should make it into stable-1.2 to avoid future discrepancies.

👍 - Rename sf2 folder to soundfonts
👎 - Leave sf2 alone, keep it sf2 for the foreseeable future.

[Wallacoloo]

According to Wikipedia, the SoundFont spec is still at version 2.04, and hasn't changed since 2005 - I think it's safe to consider it final. So what is sf3? Is it actually a widely recognized & supported format? If not, then I think the simpler thing would be to preserve the sf2 nomenclature.

But actually I vote for the change to soundfonts regardless because it provides more context to those unfamiliar with the sf2 acronym.

[Umcaruje]

I actually think all these files, such as .sf2, .sf3, .pat and .gig should go into a single folder called multisamples, this is a pretty common name among other DAWs, but this should perhaps happen when all the players get merged into a single instrument.

[tresf]

Cherry-picked to stable via de98781. Merging.

Note, although this closes #3286, official SF3 support won't arrive to LMMS until 1.3.0, or before then by running a build from master.