Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SF2 Directory Setting/Relative Paths #4180

Closed
tresf opened this issue Feb 21, 2018 · 40 comments
Closed

SF2 Directory Setting/Relative Paths #4180

tresf opened this issue Feb 21, 2018 · 40 comments
Labels
bug
Milestone
1.3

Comments

@tresf
Copy link
Member

tresf commented Feb 21, 2018 •
edited
Loading

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 #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.

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 #2982.
@tresf tresf added the bug label Feb 21, 2018
@tresf tresf added this to the 1.2.0 milestone Feb 21, 2018
@PhysSong
Copy link
Member

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.

@PhysSong
Copy link
Member

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.

@allejok96
Copy link
Contributor

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)

@JohannesLorenz
Copy link
Contributor

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?

@tresf
Copy link
Member Author

tresf commented Jan 17, 2019 •
edited
Loading

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.

@DomClark
Copy link
Member

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.

@tresf
Copy link
Member Author

tresf commented Jan 18, 2019 •
edited
Loading

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.

@midi-pascal
Copy link
Contributor

@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.

@allejok96
Copy link
Contributor

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.

@JohannesLorenz
Copy link
Contributor

@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.

@midi-pascal
Copy link
Contributor

@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.

@tresf
Copy link
Member Author

tresf commented Jan 18, 2019

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).

@tresf
Copy link
Member Author

tresf commented Jan 18, 2019 •
edited
Loading

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?

@midi-pascal
Copy link
Contributor

@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.

@allejok96
Copy link
Contributor

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)

@allejok96
Copy link
Contributor

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.

@musikBear
Copy link

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..

@PhysSong PhysSong mentioned this issue Apr 1, 2019
Closed
@Spekular
Copy link
Member

Spekular commented Apr 3, 2019 •
edited
Loading

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.

@musikBear
Copy link

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

@Spekular
Copy link
Member

Spekular commented Apr 5, 2019

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.

@zonkmachine
Copy link
Member

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

@Spekular Spekular mentioned this issue Apr 14, 2019
Closed
@Spekular
Copy link
Member

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.

@zonkmachine
Copy link
Member

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 #4944 SF2 DIRECTORY is ignored and I'm always sent to ~/lmms/samples/soundfonts/.

@PhysSong
Copy link
Member

@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.

@Spekular
Copy link
Member

Spekular commented Apr 14, 2019 •
edited
Loading

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 to C:\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.

@tresf
Copy link
Member Author

tresf commented Apr 14, 2019

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.

@Spekular
Copy link
Member

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?

@tresf
Copy link
Member Author

tresf commented Apr 14, 2019

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.

@Spekular
Copy link
Member

Spekular commented Apr 14, 2019 via email

@tresf
Copy link
Member Author

tresf commented Apr 14, 2019

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.

@tresf
Copy link
Member Author

tresf commented Apr 14, 2019

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.

@tresf
Copy link
Member Author

tresf commented Apr 14, 2019 •
edited
Loading

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

@necrashter necrashter mentioned this issue May 27, 2019
Closed
@PhysSong PhysSong modified the milestones: 1.2.0, 1.2.1 Jun 8, 2019
@JohannesLorenz
Copy link
Contributor

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

@PhysSong
Copy link
Member

PhysSong commented Jun 8, 2019

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

@Spekular Spekular mentioned this issue Aug 10, 2019
Merged
@Spekular
Copy link
Member

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

I see three solutions:

  • Pre-emptively close this as solved by Improved relative paths #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

@tresf
Copy link
Member Author

tresf commented Sep 13, 2019

#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!

@Spekular
Copy link
Member

Spekular commented Sep 13, 2019 via email

@tresf
Copy link
Member Author

tresf commented Sep 13, 2019

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

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

@Spekular Spekular modified the milestones: 1.2.1, 1.3.0 Sep 13, 2019
@Spekular
Copy link
Member

Awesome! Updated the milestone.

@Spekular
Copy link
Member

Finally, I can close this 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
1.3
Development

Successfully merging a pull request may close this issue.

Fix gig and sf2 directories being unused Spekular/lmms
Removed unnecessary SF2 directory setting
9 participants
@JohannesLorenz @DomClark @tresf @zonkmachine @musikBear @midi-pascal @allejok96 @Spekular @PhysSong