LMMS master loses Carla instrument configuration when loading old project file

[Rua]

I have an old project file created in LMMS 1.2.2, which has a track whose instrument is a Carla rack with a loaded VST. If I load this project in the latest LMMS master, then the Carla rack loads, but many of the parameters of the VST instrument are set to 0.

The problem does not seem to occur if the project was saved with LMMS master instead of 1.2.2, then the instruments are loaded correctly.

Steps to reproduce

• Open LMMS 1.2.2 with a new project.
• Add a track with a Carla rack instrument.
• Load a VST plugin with Carla and set parameters as desired.
• Save the project and exit.
• Open LMMS master and open the previously saved project.
• Open the Carla rack GUI of the track in question.

Expected behavior

The VST parameters are preserved.

Actual behavior

The VST parameters are set to zero, including things like master volume, ADSR levels, filter cutoff etc. It depends on the instrument, but it happens with at least Dexed and TAL-U-No-LX.

Screenshot

Affected LMMS versions

3518d30

The bug does not occur in 1.3.0-alpha.1, so it must have been introduced at some point since.

[zonkmachine]

Have you tested earlier builds of lmms master?

[Rua]

No, how would I do that? Downloading and building each time will take a while.

[zonkmachine]

No, how would I do that? Downloading and building each time will take a while.

Yes. Pinpointing the precise commit that introduced an issue can take quite some time. 'git bisect' is a command that speeds up the process.

The older 1.3 alpha is here:
https://github.com/LMMS/lmms/releases/tag/v1.3.0-alpha.1

[Rua]

I have been able to determine that the problem appeared somewhere in 2021. I am unable to investigate further because, for some reason, every build I make is now triggering a segmentation fault when I run it, even from commits that previously worked.

[zonkmachine]

Does the alpha above work?

[Rua]

If that's the same version that's available from the LMMS website, then yes. There is no bug in that one.

[zonkmachine]

every build I make is now triggering a segmentation fault when I run it, even from commits that previously worked.

Did you build it with debug flags?
Can you run it from gdb and get a backtrace when it crashes?

[Rua]

(gdb) r
Starting program: /home/rua/code/lmms-bisect/build/lmms 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** WEAK-JACK: initializing
*** WEAK-JACK: OK. (0)
[New Thread 0x7ffff1812700 (LWP 207109)]
qt5ct: using qt5ct plugin

Thread 1 "lmms" received signal SIGSEGV, Segmentation fault.
0x000055555577382c in ConfigManager::<lambda(ConfigManager::UpgradeMethod)>::operator()(ConfigManager::UpgradeMethod) const (__closure=0x7fffffffd8c8, 
    um=&virtual table offset 38654705664, this adjustment 10)
    at /home/rua/code/lmms-bisect/src/core/ConfigManager.cpp:145
145				(this->*um)();
(gdb) backtrace
#0  0x000055555577382c in ConfigManager::<lambda(ConfigManager::UpgradeMethod)>::operator()(ConfigManager::UpgradeMethod) const (__closure=0x7fffffffd8c8, 
    um=&virtual table offset 38654705664, this adjustment 10)
    at /home/rua/code/lmms-bisect/src/core/ConfigManager.cpp:145
#1  0x0000555555778614 in std::for_each<__gnu_cxx::__normal_iterator<void (ConfigManager::* const*)(), std::vector<void (ConfigManager::*)()> >, ConfigManager::upgrade()::<lambda(ConfigManager::UpgradeMethod)> >(__gnu_cxx::__normal_iterator<void (ConfigManager::* const*)(), std::vector<void (ConfigManager::*)(), std::allocator<void (ConfigManager::*)()> > >, __gnu_cxx::__normal_iterator<void (ConfigManager::* const*)(), std::vector<void (ConfigManager::*)(), std::allocator<void (ConfigManager::*)()> > >, ConfigManager::<lambda(ConfigManager::UpgradeMethod)>) (__first=&virtual table offset 38654705664, this adjustment 10, 
    __last=NULL, __f=...) at /usr/include/c++/9/bits/stl_algo.h:3882
#2  0x00005555557738e0 in ConfigManager::upgrade (this=0x555555d321b0)
    at /home/rua/code/lmms-bisect/src/core/ConfigManager.cpp:147
#3  0x0000555555776448 in ConfigManager::loadConfigFile (this=0x555555d321b0, 
    configFile=...)
    at /home/rua/code/lmms-bisect/src/core/ConfigManager.cpp:547
#4  0x00005555557345c8 in main (argc=1, argv=0x7fffffffddc8)
    at /home/rua/code/lmms-bisect/src/core/main.cpp:716

[zonkmachine]

You could try removing the config File, .lmmsrc.xml
When you run lmms from the build directory it will create a local one. Delete it or rename it and lmms will create a new one on startup.

[zonkmachine]

What commit are you on now?
Did you quit bisecting with git bisect reset?

[Rua]

I didn't use that command, I did it manually instead so I could understand more easily what's going on. That's how I narrowed it down to 2021 (bug wasn't there on the last commit in 2020, was there on the last commit in 2021). The gdb build above was running commit aa02a21. This build previously worked, but now it segfaults.

Removing ~/.lmmsrc.xml didn't make any difference, the backtrace is the same.

[Rua]

I found another .lmmsrc.xml in the build directory. If I remove that one as well, it starts. I have been clearing the build directory each time I start a new build with a different commit, so I guess it was reading the one in the home directory and then copying it there?

[zonkmachine]

I guess it was reading the one in the home directory and then copying it there?

No. It creates a new default File.

[Rua]

I've identified the commit that introduced the issue as f8d7fa3.

[zonkmachine]

I've identified the commit that introduced the issue as f8d7fa3.

Brilliant!
Ping @cyber-bridge !

[Rua]

I noticed that the commit message says:

The param window state isn't stored yet in a LMMS project, this is still TODO.

This seems to be related to what's going on, but I wouldn't expect previously working functionality to be broken?