VST paths are not saved relative

[Bleuzen]

In a saved project file, the path to VST plugins in Vestige is saved as absolute path. I notice that since I moved my LMMS directory. Moving or renaming the dir is not possible with this, (without destroying vst instruments in all projects).

Please use relative path to store such things, so that we are able to move or rename the LMMS directory.

[musikBear]

Vestige relates to your path in Settings, but Soundfonts path are hardcoded into the project-file. Do you mean Soundfonts?
If not, what lmms ver. and what OS?

[Spekular]

This has happened to me even with vsts in my vst directory, on RC6. Relative paths will work if you edit the mmp to use them, but they don't seem to save as relative by default

…

On Sat, Oct 6, 2018, 16:21 musikBear ***@***.***> wrote: Vestige relates to your path in Settings, but Soundfonts path are hardcoded into the project-file. Do you mean *Soundfonts*? If not, what lmms ver. and what OS? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4646 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIgVmoQxKp_h1uCpqztODz7V2DqyssTTks5uiLxbgaJpZM4XKqEA> .

[Bleuzen]

Vestige relates to your path in Settings, but Soundfonts path are hardcoded into the project-file. Do you mean Soundfonts?
If not, what lmms ver. and what OS?

Nope, I mean Vestige, and it saves absolute paths.
But soundfonts are saved relative from samples directory.

I'm using LMMS 1.2.0-RC7 on Manjaro Linux.

[musikBear]

on Manjaro Linux.

In that aspect, im from Barcelona ..

[tresf]

Please use relative path to store such things, so that we are able to move or rename the LMMS directory

We do, assuming VST is contained inside "samples". Please provide exact steps to reproduce on stable-1.2 RC8

[Bleuzen]

Well, here we found the problem. Since I have VST PLUGINS, I placed them in /plugins/vst/, not in samples.
Would it be possible to also save the relative path if they are in the plugins directory?

[Spekular]

I'll take this as an opportunity to make a proposal I've thought about a bit.

I think paths could do with being relative much more often, but ideally also with a tag attached to specify what they're relative to. There's a bunch of directories defined in LMMS's settings already, and many of them make sense as directories for relative paths.

You'd have something like
src="[relative path]" rel="[Absolute/Working/VST/Sample/Project]"

LMMS should have a ranked order of relative base locations. For example:

• Paths saved inside AudioFileProcessor should:
  • Try to make relative to the "Samples" directory.
  • If that fails (we're not in a subdirectory of "samples"), try to make themselves relative to the project file location.
  • If that fails (sample isn't in the same folder as project or a subfolder), try to make relative to the LMMS install directory
  • & so on for the remaining directories.

VeSTige would try the VST directory first, then working directory, and so on.

As long as different plugins can have different priorities, LMMS should be able to make samples relative to the most relevant folder, most of the time. However, it also becomes easier to manually edit relative paths in a project file, because you can clearly see what they're relative to.

If a sample hasn't been relative, I've had to just crop off C:\...\lmms\samples and hope for the best. Am I supposed to leave a leading \? Should I leave "samples" at the start? Can I remove "lmms" to make it relative to the working directory? With a "rel" attribute, I could explicitly specify to LMMS that I want a sample's location to be saved relative to the project file, for example. Great for tracks you've frozen to audio, or a loop you've stretched to the project's BPM or otherwise edited.

It should be possible to apply this tagging system to older project files without breaking paths, so it doesn't break backwards compatibility either.

[tresf]

The helper utility that makes paths relative is currently hard-coded for samples. Prior to this change, no VSTs were relative at all. <LMMS_WORKING_DIR>/samples can be confusing as well as undesirable for several other plugin formats, but that's how we do it today. We invite anyone to dig into the code to improve this. Note, backwards compatibility is always a concern when changing paths (or in the case of the code, changing the assumptions about file paths).

[PhysSong]

I think I can fix this issue as I suggested in #4180 (comment).
There should be no compatibility issues as LMMS can load VSTs with relative paths. In other words, this is an exception of #4180 (comment).

[kriskropd]

Having ticket #4920 closed in favor of this, can there be a consideration to simply make a utility that enables us to manipulate the stored paths contained within mmpz files? Even relying on a relative path might not be enough if those relative paths were to change dramatically.

This should be synonymous with samples and other components, so consider this: A VST previously stored in location
C:\Program Files\VSTPlugins\Xpand!2_x64.dll
becomes
C:\Program Files\VSTPlugins\Instruments\Air Music Technology\64-bit\Xpand!2_x64.dll
you can't fix that path just by simply changing the root VSTPlugins path and storing a relative path in the mmpz file.

I think a more practical solution would be to enable users to update the path locations for missing components when an mmpz file is loaded and a file/plugin is declared as missing (without having to copy or modify stored plugin parameters or piano-roll data). Ideally, even considering a text format instead of binary for mmpz files so we might substitute the new paths in batch using sed or some other text editor - but that's more of a suggestion for future mmpz format consideration and would not work for backwards compatibility sake.

[PhysSong]

@kriskropd Sorry, #4920 isn't a duplicate of this issue.
BTW, I posted a way to edit the project file: #4920 (comment)

[tresf]

Ideally, even considering a text format instead of binary for mmpz files so we might substitute the new paths in batch using sed or some other text editor - but that's more of a suggestion for future mmpz format consideration and would not work for backwards compatibility sake.

Windows (specifically GUI apps) hate stdout, but to get the uncompressed version:

"%PROGRAMFILES%\LMMS\lmms.exe" -d "%PROGRAMFILES%\LMMS\data\projects\demos\Momo64-esp.mmpz" > "%USERPROFILE%\Desktop\Momo64-esp_uncompressed.mmp"

When I say it hates, it, the above won't even work from PowerShell, so it's a very limited technique from Windows, but at least you can edit and repair your file.

[Spekular]

Closed by #5117. There's still improvements to be had here (scanning standard VST directories, locating VSTs by ID rather than path), but this specific issue is fixed.