VeSTige Searches Original Path of Assigned VST Plugin in Former System When Opening Project File

[JimmyKenMerchant]

Bug Summary

VeSTige searches the original path of the assigned VST plugin in the former system when opening a project file.

Steps to reproduce

1. Make a project using VeSTige with loading any VST instrument (VSTi) plugin.
2. Save the project.
3. Transfer the project (a .mmpz file) to another computer or system, .e.g, Linux to Windows OS. No matter whether another one has the VSTi plugin or not.
4. On another computer or system, open the project.
5. Read error messages and you can see the displayed path is your old one.

Expected behavior

VeSTige should search VST plugins using the path you set in "VST-PLUGIN DIRECTORY" on the "Setup LMMS" menu of LMMS.

Actual behavior

VeSTige searches VST plugins using the original path in a .mmpz file. The original path may include a user name of the old computer or system.

Screenshot

N/A

Affected LMMS versions

1.2.2 on Linux x86_64

Logs

N/A

[Monospace-V]

VST-Plugin directory is for VST-FX. Even with FX, I think it saves exact path. Caching VST plugin locations etc so as to run them from any path is a feature that has been suggested before. This is a virtual duplicate of other suggestions, that have mentioned saving relative VST path (issue 4646) (can be done, I think, if VST is saved in Samples folder of lmms), all the way to being able to run a VST if detected wherever in the system it is (issue 4907).
Requesting you to look for others asking the same thing before filing bug reports.

[JimmyKenMerchant]

VST-Plugin directory is for VST-FX. Even with FX, I think it saves exact path. Caching VST plugin locations etc so as to run them from any path is a feature that has been suggested before. This is a virtual duplicate of other suggestions, that have mentioned saving relative VST path (issue 4646) (can be done, I think, if VST is saved in Samples folder of lmms), all the way to being able to run a VST if detected wherever in the system it is (issue 4907). Requesting you to look for others asking the same thing before filing bug reports.

This is an issue specified on VeSTige. Saving an absolute path of the old path in a project file may expose a user name of Linux. This issue may cause any privacy breach on sharing project files, *.mmpz. When loading a VSTi plugin to VeSTige, the folder assigned at "VST-PLUGIN DIRECTORY" opens in the menu. This is the evidence that VeSTige recognizes "VST-PLUGIN DIRECTORY" is the primary folder.

[JimmyKenMerchant]

Note that the function around this issue seems to be 'vestigeInstrument::loadFile( const QString & _file )' in "master/plugins/vestige/vestige.cpp (94363be on Jul 4, 2020)". I find out Line No. 352 shows the identical error message on opening project file. 'vestigeInstrument::loadSettings( const QDomElement & _this )' uses 'loadFile' and the path is quoted from '_this.attribute( "plugin" )'. I guess the QDomElement is from saved project, and '_this.attribute( "plugin" )' is the saved original path. I prefer to change '_this.attribute( "plugin" )' to the combination of the variable to store the path of "VST-PLUGIN DIRECTORY", 'ConfigManager::inst()->vstDir()' and the file name of the VSTi plugin. This variable has been already used on Line No. 705 in 'VestigeInstrumentView::openPlugin()'. In addition, "plugin" attribute is saved on Line No. 266 in 'vestigeInstrument::saveSettings'. On this process, only the file name of the VSTi plugin should be stored without the original path.

[Spekular]

Fixed in 1.3.

[JimmyKenMerchant]

I confirmed this issue is fixed in 1.3.0-a, and 17565ca was the commit. lmms/src/core/PathUtil.cpp makes a virtual relative path, 'uservst:*.dll', and vanishes an original absolute path including a user name. I think it would be complicated and I may suggest a patch for 1.2.2.