Lmms: SF2 Directory Setting/Relative Paths

Created on 21 Feb 2018  Â·  40Comments  Â·  Source: LMMS/lmms

Spin-off from #3810...

There are two named settings that pertain to soundfonts...

  1. There's a path called "SF2 DIRECTORY"
  2. There's a path called "DEFAULT SOUNDFONT FILE"

screen shot 2018-02-19 at 9 50 51 pm

Unfortunately the software doesn't really make use of either of these when calculating relative paths, and I'm not sure we ever will, but I feel this is a bug.

Soundfonts were decided to be stored inside samples/sf2, discussed in https://github.com/LMMS/lmms/issues/1807 and implemented in https://github.com/LMMS/lmms/pull/1908 and then renamed to samples/soundfonts in https://github.com/LMMS/lmms/pull/3895.

What seems to be the missing puzzle piece here is that we added an option for a "SF2 DIRECTORY" folder, but we ignore it. I think it simply needs to be removed.

I'm sure there will be a few people asking to have their SF2 directory outside their samples directory, but still relocatable, but it's simply not something we support. If you can point me to a regression that occured between 1.1.0 and 1.2.0, I'll consider writing a patch for this, but at a glance it appears the bug was adding this location to the UI to begin with.

This is not to be confused with storing samples relative to project files, which is outlined in https://github.com/LMMS/lmms/issues/2982.

bug

Most helpful comment

Awesome! Updated the milestone.

All 40 comments

Unfortunately the software doesn't really make use of either of these when calculating relative paths, and I'm not sure we ever will

There can be some compatibility issues if we use some paths which weren't used. I think we can use them for loading first, and then for saving.
I don't know if this is needed for 1.2, but I think we should eventually do this.

Maybe off-topic, but I think we can just pull tryToMakeAbsolute/tryToMakeRelative out of SampleBuffer and use suitable search paths according to the context. It'd be nice for VST plugins, too.

This may be it's own issue/enhancement... but it relates to this problem. Look at it as a compromise solution.

Currently: When opening a project that contains references to a SF2 that doesn't exist, the invalid paths are replaced by the default soundfont path. Saving it will save the "broken" version.

First of all the broken paths should be left alone. Simply opening and saving a project shouldn't break it if some paths are missing. We don't do that with missing sound samples, right?

Second, let's say the original author had his soundfont in some a weird absolute path. I have the same soundfont, but in another place. Instead of having to change the soundfont for each of the tracks, it would be nice if LMMS could interactively search and replace the missing fonts. "There are 33 tracks with a missing sound font '/home/denny/sgm_v1.sf2'. Do you want so select a new path for the soundfont?" ... And do this for each unique soundfont path.

(A little side track, this may be a bug just for me: If the original sf2 was a different one than the default, let's say SGM got replaced by Fluid, the track does not produce sound until I go into the instrument bank and re-select the instrument. Currently on 1.2.0-rc6, but have been like that forever)

Unfortunately the software doesn't really make use of either of these when calculating relative paths

I don't get what you mean @tresf . Can you please explain?

Unfortunately the software doesn't really make use of either of these when calculating relative paths

I don't get what you mean @tresf . Can you please explain?

The decision to move SF2 files inside samples/soundfonts rendered these location unused per original bug report...

Soundfonts were decided to be stored inside samples/sf2, discussed in #1807 and implemented in #1908 and then renamed to samples/soundfonts in #3895.

We should do one of the following:

  1. Make sure the fields are unused and remove them
  2. Actually use the fields

I'd vote for the first. The second can be a future feature slated for a future version.

I think the "Default Soundfont File" option is still useful: this is the soundfont used when a new Sf2 player is added. Sf2 player is the instrument used when importing MIDI files, so this can save time loading soundfonts into every track when a MIDI file is imported, and also means that an imported MIDI file can be immediately played and produce sound, which I think is more intuitive for new users.

also means that an imported MIDI file can be immediately played and produce sound, which I think is more intuitive for new users.

In the rare chance it's set. The way media players handle this is they bundle a basic soundfont(s) for playback. Although I agree that some sound is better than no sound, the default is no sound currently. I'd rather see some homemade, bundled soundfonts or instrument presets handle this. The existing functionality can remain but it's not intuitive or very useful.

@tresf I disagree. This is the first step I do when I setup LMS.
When importing a new MIDI file, this is the way I decide if it worth working on it or not.
My default soundfont is a very good one (Titanic) and the first listening with Sf2 player is crucial for the way I use LMS.
The overhead of setting a soundfont for each track individually for a one time listening is not productive for me.
Everyone does not use LMMS (I do for years) for the same purpose.
The "Default Soundfont File" option does not hurt anyone, set or not.

The overhead of setting a soundfont for each track individually for a one time listening is not productive for me.

May I ask, @midi-pascal, when you import a project with a lot of different soundfonts, which you do not have, do they all get replaced by Titanic and does the tracks produce sound? If so it seems that the option for default soundfont fills it's purpose.

@tresf Still, I don't get what that has to do with relative paths.

FYI, the sf2 directory is currently only used when the file dialog is opened an no file was previously specified.

@allejok96 I do not import LMMS projects at all. Basically my work flow is to import a pure MIDI file, listen to it and, if I like it, re-orchestrate/add tracks/change instruments or various MIDI settings until I am satisfied with the result. Then I save it as a wav or mp3 file and add it to my music library.

FYI, the sf2 directory is currently only used when the file dialog is opened an no file was previously specified.

I believe you're confusing the two. This value is always samples/soundfonts (relative).

Regardless, relative paths are always relevant, they make project files relocatable (and eventually portable).

The "Default Soundfont File" option does not hurt anyone, set or not.

Albeit out of scope for 1.2, I would vote that we take this UI option away and ship a default, good, (and legally cleared) soundfont like the titanic one you mention. With this change made, a user can always override the default soundfont file in the LMMS WORKING DIRECTORY if they care that much about overriding the default.

this is the way I decide if it worth working on it or not.

Right, it's a way to preview the file, not actually use it. The midi file can generally be previewed with a media player which avoid searching, testing and installing a soundfont into a (most likely) non-relative path.

We're not the only DAW to allow MIDI imports, how do the others do it? Do they have a good, default soundfont?

@tresf Your idea to ship LMMS with a default soundfont is very interesting but, good quality soundfonts are big: Titanic is more than 275 Mb. On the other hand this allows to play MIDI files in Sf2 player with no additional download, which, on the point of view of simplicity, is a plus.
I chose LMMS years ago because of its self-contained concept (except for the soundfont): You install and you are ready to play. No Jack setup, no complicated settings, no trouble :-) Just import a MIDI file, click the "Play" button and you are in business.
I tried some other FOSS DAWs: Qtractor, RoseGarden, Ardour (No MIDI) and some more obscure ones and I really want to insist on that LMMS kills the others ones on many aspects: easy to learn, easy to use, neat UI, no need to setup technically challenging external I/O.
From the ones I tested, none comes with a default soundfont.

I agree with @midi-pascal on the size issue. Having lmms be small and neat is good.

Most people who can download and install lmms can download a soundfont, if they get some push in the right direction. I don't think that is a big issue. Problem becomes: what soundfont is good, and where to get it? For now the solution is just lots of google, download and try.

There could be a recommended default one available for download at the lmms website. But then where do the user put it? We don't want a mess with absolute paths, and stuff outside the lmms directory?

There could also be the wine way. Asking if you want lmms to download the soundfont for you at startup. (Don't you just hate that? It would have to have a "do not ask again" box) But that would require more coding and urllib or whatever (I'm a python guy, woe is me)

Another suggestion: keep the default soundfont path settings box. Have it set by default to "samples/soundfonts/defualt.sf2" if that file exists. Make a self-extracting archive with titanic that instslls itself to that spot. Put it up on the website and call it something like "Default soundfont pack for LMMS". Nerds happy, noobs happy, dial-up suckers happy.

Interesting conversation
Imo SFs are connected to issues, that plaque new users:

  • Importing a MIDI-file without having a defined 'Default-SF' creates a silent and apparently flawed project

That would be fixed by tresf suggestion of including a SF in LMMS! However -witch one?
Imo it would be insanity to bloat LMMS to 4-500 MB 'titanic' download!
-I would rather hit the iceberg..
GeneralUserGS (31MB) covers SF needs of programs like Anvil, but even that would bloat a LMMS dl to double size!
Imo there should not be bundled SFs (nor GIGAfonts) with LMMS.
However, it could be a solution, that LMMS makes a check in Settings, when a MIDI-file is being loaded.
If the user do not have a defined "Default-soundfont", LMMS would respond with a message like..

You are about to load a MIDI-file!
However MIDI-Flies needs a soundfont to create the instruments!
You do not have a defined Soundfont installed!
Do you want LMMS to find a Soundfont, and install it for you?
Y/N

Then this particular user would make an additional dl. Only now there would be generated more traffic, and it would only happens once, for each user.
Lastly..
Does a royalty free generalGS exists? Minor point, but a point..

As far as I can tell from this conversation, the SF2 Directory is completely unused, but it's not entirely clear to me whether or not the Default Soundfont File path is used or not.

whether or not the Dedault Soundfont File path is used or not.

In my 32b rc8 it is. All new vanilla SF2 is natively loaded with the GeneralUserSF2 ad i have defined as Default Soundfont File in Settings
There are no other way for LMMS to set that file, than reading the Default Soundfont File from Settings

Then it seems to me the SF2 directory should be removed (since it's unused) and the default soundfont file path kept (since it works). Alternatively, milestone this for 1.2.1 or something, it seems like a silly thing to hold up the stable release.

If there is no objection, let's bump this to 1.3.

No need for a bump anymore, as far as I'm concerned. I've fixed the sf2 and gig directories so they're used when opening a file browser, so now both parts of this issue are working as intended.

I don't understand this issue. If I add a new sf2 player I will see it loaded with the default soundfont. If I don't have a default soundfont set and I click the folder icon to load a new soundfont the SF2 DIRECTORY will open up. Maybe it would preferable if the default soundfont was used primarily when importing a midi file and the path in SF2 DIRECTORY for loading soundfonts via sf2 player manually?

@Spekular With the fix in https://github.com/LMMS/lmms/pull/4944 SF2 DIRECTORY is ignored and I'm always sent to ~/lmms/samples/soundfonts/.

@Spekular With the fix in #4944 SF2 DIRECTORY is ignored and I'm always sent to ~/lmms/samples/soundfonts/.

We previously used m_sf2Dir via sf2Dir(), but the patch uses workingDir() + SF2_PATH via userSf2Dir(). I think that's the reason.

Testing again.

Windows, 1.2.0-RC8, no default soundfont:

  • sf2 directory set to C\Users\Spekular\lmms\samples\sf2

    • File browser opens to C:\Program Files\LMMS

  • sf2 directory set toC:\Users\Spekular\Desktop

    • File browser opens to desktop.

Ubuntu, no patch, no default soundfont:

  • sf2 directory set to /home/spekular/Documents/lmms/samples/soundfonts

    • File browser opens to /home/spekular/lmmsdev/lmms/build

  • sf2 directory set to desktop

    • File browser opens to desktop

Ubuntu, patch, no default soundfont:

  • sf2 directory set to /home/spekular/Documents/lmms/samples/soundfonts

    • File browser opens to /home/spekular/lmms/samples/soundfonts

  • sf2 directory set to desktop

    • File browser opens to /home/spekular/lmms/samples/soundfonts

It does seem like the patch actually breaks things rather than fixing them, it just looked good from the first (and only, oops) case I tested.

Doesn't this imply that the original issue is invalid, though?

I'm also a little confused as to why userSf2Dir() returns an unchangeable default directory and sf2Dir() returns the... user's sf2 directory.

I'm also a little confused as to why userSf2Dir() returns an unchangeable default directory and sf2Dir() returns the... user's sf2 directory.

It was the only way to make them relative. Breaking portable working directories is very bad.

I was referring to the functions' naming, I find it confusing.

More importantly, @tresf what exactly is the issue with the default sf2 directory? It seems to work just fine right now. The case where it fails is when the selected directory doesn't exist, in which case it goes to the install directory. Would you rather create the folder if it's gone? Fallback to a different folder?

what exactly is the issue with the default sf2 directory?

What's it for? A browse dialog? That's a bug, it's supposed to be in samples, it should default there.

This isn't a show stopper for 1.2 but it's a bug nonetheless.

So, the ability to configure a default soundfont path is a bug, because it
shouldn't be configureable?

On Sun, Apr 14, 2019, 16:07 Tres Finocchiaro notifications@github.com
wrote:

what exactly is the issue with the default sf2 directory?

What's it for? A browse dialog? That's a bug, it's supposed to be in
samples, it should default there.

This isn't a show stopper for 1.2 but it's a bug nonetheless.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/LMMS/lmms/issues/4180#issuecomment-482983834, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIgVmkt_mCJGnj6dtMFHLbK67VwKUoyuks5vgzY-gaJpZM4SNEkW
.

So, the ability to configure a default soundfont path is a bug, because it
shouldn't be isn't currently configurable?

Fixed, and yes, correct.

I feel this is all explained perfectly fine in the bug report....

Unfortunately the software doesn't really make use of either of these when calculating relative paths, and I'm not sure we ever will, but I feel this is a bug.

Soundfonts were decided to be stored inside samples/sf2, discussed in #1807 and implemented in #1908 and then renamed to samples/soundfonts in #3895.

What seems to be the missing puzzle piece here is that we added an option for a "SF2 DIRECTORY" folder, but we ignore it. I think it simply needs to be removed.

The parts about the default soundfont file were veto'd so ignore any requests to remove that. :)

Just as an update: PR #4995 wanted to fix this by removing the SF2 directory, but the PR got rejected.

Bumping to 1.2.1 since there's no reason for this to block the 1.2.0 release.

Should this be closed, redefined, or re-milestoned?

  • #5117 makes proper use of this directory, so removing it seems unwise
  • I don't think #5117 should be merged for 1.2.1, so that solution won't fix this for the current milestone

I see three solutions:

  • Pre-emptively close this as solved by #5117 or a successor/replacement PR

    • Re-milestone this for 1.3

    • Redefine the proposed solution. For example, leave the directory code in, but indicate that it's not used yet via warning text or graying out the selector in the settings

5117 makes proper use of this directory, so removing it seems unwise

Just add "Closes #4180" to the PR and remilestone for 1.3.0. This will auto-close when #5117 is merged.

As the OP, yes, if you make use of this directory, the bug can be closed. Thanks for the work on it!

I don't have the ability to change milestones, though.

On Fri, Sep 13, 2019, 05:56 Tres Finocchiaro notifications@github.com
wrote:

5117 https://github.com/LMMS/lmms/pull/5117 makes proper use of this

directory, so removing it seems unwise

Just add "Closes #4180 https://github.com/LMMS/lmms/issues/4180" to the
PR and remilestone for 1.3.0. This will auto-close when #5117
https://github.com/LMMS/lmms/pull/5117 is merged.

As the OP, yes, if you make use of this directory, the bug can be closed.
Thanks for the work on it!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/LMMS/lmms/issues/4180?email_source=notifications&email_token=ACEBLGQZFBGZT5LL4QHNLRLQJMFPJA5CNFSM4ERUJELKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6T4KDY#issuecomment-531088655,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACEBLGUIGQRIKOIYPRA766DQJMFPJANCNFSM4ERUJELA
.

I don't have the ability to change milestones, though.

Apologies. Invite sent which should grant you access to do that.

Awesome! Updated the milestone.

Finally, I can close this 🎉

Was this page helpful?
0 / 5 - 0 ratings