Hardcoded paths in mmp and mmpz files

Having trouble with LMMS? Ask about it here.
Oh dear. I've just had to reinstall LMMS on a new PC because my old one died, and took the opportunity to rationalise my drives. This means that the default drive, and thus paths for LMMS are now different. But it appears that project files contain hardcoded paths to VST instruments,, eg this extract from one of my project files saved as .mmp:
<instrument name="vestige">
<vestige plugin="F:/Synths/VSTs/StringZ2.dll"
(original path for VSTs was F:\Synths, new path is D:\Synths), and therefore most of my projects now break, warning that they cannot find the necessary instruments.

This is on A PC, so I can SUBST D as F to fake the existence of the original drive - but is there any way of globally updating a project to honour the new default paths, or a way for LMMS to automatically ask if I want to replace an instrument if it cannot find it? The alternative - manually fixing every instrument in every project - will be a long task

Mike
SpeakEasy wrote:
Fri Aug 23, 2019 1:06 pm
Oh dear. I've just had to reinstall LMMS
I will stop you right there, grab your hand and cry together in unison...
Its a biiig yes.....
Migrating between pc's is as visiting Hades
Lets look at the issue: What is involved
1)Soundfonts
2) Samples
3) Saved presets

However not your VSTs!
For VSTs all you have to do is to place all VSTs dlls in the folder you have defined for VSTs in your settings!
That should solve your immediate issue.

What is planned:
There has been several ideas. The issue will be tackled with a methods where LMMS will search for all missing objects, and if found, load them.

That will eradicate the issue completely!
But
Though planned and agreed, there is nothing scheduled.

What you could / should do:
Install LMMS in default suggested folders!
This mean that LMMS will be installed on your C drive. Most often on modern pc's -a SSD that also holds your OS.
DO NOT INSTALL IN THE WINDOWS FOLDER!
The benefit of LMMS on your SSD, is lightning-fast project & resources loading
The adverse : writing on your SSD, hence wearing the cells :|
And No -this is neither optimal or a satisfying solution -sorry
You already know about opening and reading MMP-files, and im afraid thats how you need to tackle it: Manually :|

Fortunately the mmpz-file content is not altered from being opened with 'missing-elements' and the saved as mmp.
For my self, i have decided not to do this in bulk. If i like to open a specific project, and there are issues, then i tackled them, for that file
And yes, i have thought about writing a program in 'my language' that can handle this, and if i do, i will share it, meanwhile we just have to hope for the auto-search-feature
Many thanks for your response

>all you have to do is to place all VSTs dlls in the folder you have defined for VSTs in your settings!
They are

>That should solve your immediate issue.
Bu sadly it doesn't. As I described in my post, on the original setup the VST-PLUGIN directory was defined as F:\Synths, and on the new PC as D:\Synths. D:\Synths is an exact clone of the original F:\Synths and LMMS moans that it cannot find any VST that Vestige is looking for.

>Fortunately the mmpz-file content is not altered from being opened with 'missing-elements' and the saved as mmp.
Again, sadly not my experience. When I initially encountered the problem I immediately saved the mmpz project I had just opened as an mmp, and found the following (as an example):

<Instrument name="vestige">
<vestige plugin=""/>
</instrument>

Which clearly shows that the reference to the relevant VST has been removed. Perhaps I am doing something really odd ...

This is all with version 1.2.0 on W10

Of course, none of the above really changes your general advice, so I'll just have to do it all manually.

Glad to hear a future fix is planned. Sad to hear it won't be for a while :-)
SpeakEasy wrote:
Fri Aug 23, 2019 5:04 pm
<Instrument name="vestige">
<vestige plugin=""/>
</instrument>
Nooo c*** its my stupidity, i do it different :|
Oki this is a bit more 'technical' but i think you can follow
Correctly formed mmpz can be converted to mmp! LMMS reads a cmd-line skript, and resave the mmpz as mmp :


Pre requests:
You have your
* LMMS on D:
* lmms.exe in d:/lmms
Open cmd (run| cmd
type or copy skript

Code: Select all

D:
cd LMMS
lmms.exe -d <path+Directory for the mmpz-file>/<inputmmpzFile.mmpz > <path+Directory for the mmp-file>/outputmmpFile.mmp
I believe that should work for one mmpz file at the time, and that should preserve everything!











Of course, none of the above really changes your general advice, so I'll just have to do it all manually.

Glad to hear a future fix is planned. Sad to hear it won't be for a while :-)
[/quote]
Aha! Perfect. I'll try that later. If it works (which I am sure it will) then it'll be no trouble to write some script to loop through all the mmpz files and then to modify the resulting mmp files (programmer in a past life …).

Once again, thanks.
This should work on Linux too, but as I type this, not sure on how to do the lmms.exe part on Linux.


Could be it's just lmms - d. ( assuming those options are the same for the Linux version of course )
And work with app-image version.

:)
Gps wrote:
Sun Aug 25, 2019 11:48 pm
how to do the lmms.exe part on Linux.
Is there no executables in linux? It the file that is the target-file in your shortcut, that is the runnable file
Linux differs from this compared to windows.
Linux does not care about the extension for starters.

Some program files have an .so extension. Some don't.

There is also no register.


I just did a test to start lmms, from the command line in Linux, and its just type lmms :P
As you can see in the code below.
I also see it complaining about carla. :P

Code: Select all

guus@linux-0pkp:~> lmms
Notice: could not set realtime priority.
Cannot load library /usr/local/lib/lmms/libcarlapatchbay.so: (libcarlabase.so: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet)
Cannot load library /usr/local/lib/lmms/libgigplayer.so: (libgig.so.7: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet)
Cannot load library /usr/local/lib/lmms/libcarlarack.so: (libcarlabase.so: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet)
Cannot load library /usr/local/lib/lmms/libcarlabase.so: (liblinuxsampler.so.4: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet)
guus@linux-0pkp:~>



Its in dutch for some part.
Its saying it cant find certain carla related stuff.

But this means it would be for linux:
lmms -d and then the paths. :)
Gps wrote:
Mon Aug 26, 2019 5:38 pm
it would be for linux:
lmms -d and then the paths. :)
did that work?
Gps this is right until you use an installed lmms via package.

If you use the appimage I guess you should replace lmms bu the name of the appimage file and being in the right folder.

Do you use an appimage or an installed lmms via a repository?