Hardcoded Path in project-files

[musikBear]

I wonder why lmms has hardcoded path information in project-files. The reason is a forum-user that has bought a new pc.
His former pc was quite weirdly partitioned -dont ask why, i dont know
But he had a folder structure
D:/a/b/c/d/
And then a folder with soundfonts
That was his default sf path, and the one he had in his lmms settings
So ~200 projects had this information in each project:

          <instrument name="sf2player">
            <sf2player patch="81" chorusLevel="2" chorusDepth="8" reverbOn="0" reverbRoomSize="0.2" chorusOn="0" chorusSpeed="0.3" reverbDamping="0" chorusNum="3" reverbLevel="0.9" bank="0" reverbWidth="0.5" src="D:/a/b/c/d/soundfonts/GeneralUser GS Live-Audigy v1.43.sf2" gain="1"/>
          </instrument>

Now he got a new pc
He now installed lmms as default in C
None of his 200 projects can load
Why is the src= not just a reference to the path made in lmms-settings
Is there a special reason, that the information must be added to the project-file as a hardcoded string, and not as a reference to the directory in lmms-settings
The same goes for all other src=
It would be best if they were references to just one constant namely the strings in lmms-settings

[tresf]

None of his 200 projects can load

Beta = bugs. Tell him sorry. He should be able to open and save with RC4 on the original PC and it should fix the problem. 200 projects is quite high, I would assume only newly created projects with RC1/RC2 would have this bug. If it still happens with RC4 have HIM open a new bug report.

On a side note... @musikBear STOP filing bugs for other people please. Just send them to discord (lmms.io/chat) or directly here. Being a translation layer between the problem and the description is kind, but unnecessarily complex. Describe the problem and move on without dramatics.

Closed via #3540 #3510. Duplicate of #3533. Please ask to reopen if the problem still exists in RC4.

[musikBear]

Please ask to reopen if the problem still exists in RC4.

Im afraid it does. This time yet another user cant open his project's Soundfonts, in a different pc.
I made an experiment.
I Took a midi import, with my default SF2 and saved it as mmp.
I then opened this project in code-editor, and replaced the path to a different partition (from E to C)
Eg the exact same situation, as if i had changed pc.
This causes lmms rc5 to show

I still feel that the simplest way around this, would be to have lmms look in the Settings, and load elements according to the paths in Settings. That would make cross-usage of projects only depend on users having the same resources. The hardcoded paths in projects, could be phased out.
I realize, that faulty setup will impair this solution.

[tresf]

Don't talk about "another user". Stop, stop, stop acting as a surrogate.

If you have a a bug with midi import, open a new bug report. There's no "relaying bugs", there's no "experiments". Either the software works or it does not and exact steps are required to reproduce.

There are rare exceptions to this where intermittent bugs can't be 100% reproduced, but this is not that case. Please offer value or stop using our tracker.

[musikBear]

Eg the exact same situation, as if i had changed pc.

Tresf - you need to read what is written.
My experiment demonstrates that the relative path does not work

Closed via #3540 #3510. Duplicate of #3533. Please ask to reopen if the problem still exists in RC4.

It does exists in RC5, So this is a request to reopen the issue.
I gave a background for the experiment, but the experiment, ao guideline to reproduce, is totally transparent to any users problem.
And it has absolutely nothing to do with midi.

[tresf]

Steps to reproduce and we'll reopen. I'm not sure how much clearer I have to be here.

[tresf]

There are two named settings that pertain to soundfonts and your most recent post makes this confusing (as is your original bug report) but I'll specify, clearly. Please consider this in the future to avoid this back and forth which is a waste of developer time.

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

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

[tresf]

Edit: So please ask the users to start using "LMMS HOME DIRECTORY" (Edit2: Specifically, samples/ ...) to avoid this problem in the future and contain the soundfonts within the LMMS provided soundfonts folder. That will be relocatable.

In regards to the 200 projects in the original bug report that are now "unusable", have the user drop over to #programming on Discord. A few line script could export all 200 projects to .mmp and use sed to search/replace the old absolute paths to whatever the user needs at the new home. Let the users know this will continue to happen in the future if "LMMS WORKING DIRECTORY" is not being used.

Unfortunately at this time, batch conversion of .mmpz -> .mmp isn't available on Windows yet, so this would have to be done on Mac or Linux. 😕

[musikBear]

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

No that is not relevant. What i did is to simulate using a different pc:
If you have more pcs than one, you dont have to do this, just create a project on pc1 and open it on pc2.
I create a simulationof that situation this way:

• Create a mmp-project with a couple of sound-fonts
• Edit the mmp in code-editor
  ** change partition for lmms installation
  Eg:
  src="C:\LMMS\lmms_working_dir\projects\presets\soundfonts\GeneralUser GS Live-Audigy v1.43.sf2" reverbWidth="0.5"/>
  Is changed to
  src="E:\LMMS\lmms_working_dir\projects\presets\soundfonts\GeneralUser GS Live-Audigy v1.43.sf2" reverbWidth="0.5"/>
  For each of the path in the project-file.
  That is what you would see, if lmms was installed on two different pc's.
  Same project, but on different pc's
  Then reopen the latter project on the factual pc, and it open the project but fails to find the soundfonts, because their actual placement are on C: and not on E: as is now written in the project-file.
  Recreation end.
  That is the reason that i ask, why lmms need to have this hard-coded string inside a project, instead of reading this in settings. (but here you are correct, i missed the SF2 ambiguousness between default-SF and the SF-library).
  If lmms during project-loading read the strings from Settings, then the project would also load the instruments, if both pc had them.
  It is the written strings inside the project-file, that blocks for this, and causes the pop-up i posted above.
  Again i ask: Why are those strings eg:
  "C:\LMMS\lmms_working_dir\projects\presets\soundfonts\GeneralUser GS Live-Audigy v1.43.sf2"
  written in the file, when it is possible to pick the factual placements, from the project-loading Settings| paths ?
  Remember that sound-font is only an example. It is true for every instrument. Paths are written inside the project-file.

[tresf]

@musikBear if you read the above reply, you can see the soundfonts must reside within the samples directory (NOT projects). If you're not doing this, it won't work, I'm sorry.

If you'd like all files to be relevant to the project path, then you've opened a duplicate of #2982. This has never been supported.

[tresf]

Closing marking as duplicate of #2982.

[musikBear]

if you read the above reply, you can see the soundfonts must reside within the samples directory (NOT projects). If you're not doing this, it won't work, I'm sorry.

I now see why i havent had this issue. I do not have 'stand-alone' soundfonts. 'All' (I have 5..) are embedded in Lmms-soundfont-player and saved as *.XPFs.
Thats why i did not know that strange prerequist for SF2s to be in samples, mine is not. they are in lmms-presets, and in XPF format
Now here is a longshot
Couldent mandatory SF2 embedding in soundfont-player and saved as XPFs be an idea, to circumference need for Sf2s in Samples-folder ?

[tresf]

Couldent mandatory SF2 embedding in soundfont-player and saved as XPFs be an idea, to circumference need for Sf2s in Samples-folder ?

There's no such thing as "embedding" a soundfont in an XPF file. It's theoretically possible (e.g. base64 blob) but it won't ever happen because soundfonts are generally very large in size.

that strange prerequist for SF2s to be in samples, mine is not. they are in lmms-presets, and in XPF format

A .sf2 file is a patch and we discussed for a while about where best to store these. They're like a cross between a plugin and a sample, but actually store multiple samples inside them. .gig files fall into this category and I've crosslinked all of the discussion surrounding those decisions.

In an LMMS project file, all instruments are still saved in XPF format, just internal to the project. XPF files are actually the one file that is never cross-references inside an LMMS project, it's copied directly into the project. This means it's not that common nor that useful for an XPF to contain a soundfont patch. There are use-cases where this makes sense, but most people will simply drag a soundfont into a new track and not rely on preset information although you're free to use it how you wish so as long as you keep things organized properly.

Organization is as follows... if there is a specific combination of XPF preset and SF2 sample you would like to re-use in your projects, you will need to save your presets inside the proper presets folder and your samples inside the proper samples folder. This is no different than .ogg, .flac, .wav. You wouldn't store your presets and your samples side-by-side despite them being related. This may be undesired, but I think that would be a better conversation for #2982 as the use-case is nearly identical albeit presets instead of projects.

You may also consider talking through these bugs in our #support channel on Discord. We're answering questions just like these all day long there.

[musikBear]

You wouldn't store your presets and your samples side-by-side despite them being related.

Ok, that is how i have my 5 SF2, and all as .XPF. I will then ofcause not have any SFs in samples library, and no issues loading them. 👍

[tresf]

Ok, that is how i have my 5 SF2, and all as .XPF. I will then ofcause not have any SFs in samples library, and no issues loading them. 👍

Again, storing samples relative to projects/presets is not yet supported, they must reside inside samples currently. If you have any more information to offer the topic, they're best suited for the original bug report here: #2982.