Hello.
LMMS RC4.96 freezes for a long time when pressing "Add effect" in "FX-Mixer".
I don't know, is it needed, but I added strace output.
(sudo strace '/home/vlad/Programs/audio/lmms-1.2.0-rc4.96-linux-x86_64.AppImage' --allowroot)
Line in terminal was before I pressed "Add effect button":
wait4(-1, VST sync support disabled in your configuration
Strace output before closing (I pressed button, it's loading now):
https://pastebin.com/RBymNjPh
Total strace (after closing window): https://pastebin.com/zsFaih3j
System: Linux Mint 18.2 x64 Cinnamon.
Jack was installed from standard repository with "aptitude install qjackctl".
Do only I have such issue ?
It appears in both cases: when I'm trying to add effect in "FX-Mixer" and in instrument's "FX" tab.
Description sounds like it may be a duplicate of #3631 however we've changed around some VST code in the the latest 1.2.0 betas so this may be new or may be AppImage related.
@tresf , btw., I installed new Linux Mint system, now this bug is absent.
I remember that in some pull request I described similar with it bug, figured out why it happened.
I'll find that info soon and update this issue.
I believe this is not a duplicate of #3631
It's an issue that happens to many users on linux. Users' VST plugin directory gets set to their home folder and LMMS hangs because of the magnitude of the files it needs to scan. I think there's some place in the config manager where we default to the home directory.
I had this issue the first time I opened the latest AppImage (1.2.0-rc5). It took forever for the effects screen to show up but after it did then pressing the "Add Effect" button worked a lot faster but noticeably delayed.
Just now I tried closing and reopening LMMS. The first time I click "add effect" it takes between 10 and 20 seconds to open (a lot less than the first time around) and later clicks take about 3 or 4 seconds.
I will create a new issue for the "small delay" even after you open it the first time because it's a lesser issue but still pretty annoying on its own (and hopefully fixable).
The population of the EffectSelectDialog does some blocking operations when it scans for plugins. I recommend starting there. It may be a matter of queuing up the plugins in a non-blocking manner, or simply providing better visual feedback while the scanning is occuring. I feel tracking every UI nuance is what's causing this tracker to get overrun with requests. Instead, I'd recommend someone debug the code and help make the UI responsive. Qt has some very nice signal/slot logic that allows background threads to update the UI rather nicely.
Also, please specify the Window manager you're using. I've tested this on Windows, Mac and Ubuntu 14.04 and none of them take "10 and 20 seconds" to open. This is excessive. On Mac the screen does take about half a second to open and even that in frustrating to deal with.
Another item worth investigating is whether or not you have the lmms LADSPA plugins installed from another repository. There may be some inefficiencies when the stock OS locations are being scanned from within the AppImage. Normally, the AppImage should bundle it's own LADSPA and native plugins, but IIRC, the OS location is hard-coded in Linux to look in the stock locations for LADSPA too, so if you can provide some unit-tests to reproduce this problem, it may be something we need to add to the settings dialog to skip some built-in places (optionally of course) now that we've had the addition of the AppImage where everything is contained. Alternately (if the stock location is the cause) we can adjust our documentation to warn about this scenario.
I am not interested in producing unit tests. If I can help determine if the plugins are in the AppImage bundle or not I'll be glad to help.
I am using KDE Plasma as my desktop environment.
I am not interested in producing unit tests. If I can help determine if the plugins are in the AppImage bundle or not I'll be glad to help.
Since your system reproduces this issue and most others don't, the more information about your specific setup the better. Unit testing is exactly what the project needs assistance with.
The more information you can provide, including performing your own troubleshooting, the better. If you do not, then you will reduce the chances of this being resolved in a timely fashion. If a developer cannot reproduce after a while, it will be closed as wontfix because insufficient information was provided.
I'm happy to provide any reasonable information a developer may find useful. Given that I use a largely unmodified Debian-testing installation, I find it very unlikely that I'm the only one experiencing this - although I might be the only one reporting it, as those things normally go anyways.
If anything @vlad1777d's original report goes to show the same.
I'm happy to provide any reasonable information a developer may find useful.
This part, it's only a guess though...
Another item worth investigating is whether or not you have the lmms LADSPA plugins installed from another repository. There may be some inefficiencies when the stock OS locations are being scanned from within the AppImage.
I haven't installed LMMS from 3rd party sources in a long time so the vast majority of my systems wouldn't have these installed, which is why I suspect this to be the cause.
According to the source code, it LMMS looks in the following locations for Linux and Mac:
src/core/LadspaManager.cpp#L50
ladspaDirectories.push_back( qApp->applicationDirPath() + '/' + LIB_DIR + "ladspa" );
ladspaDirectories.push_back( "/usr/lib/ladspa" );
ladspaDirectories.push_back( "/usr/lib64/ladspa" );
ladspaDirectories.push_back( "/usr/local/lib/ladspa" );
ladspaDirectories.push_back( "/usr/local/lib64/ladspa" );
ladspaDirectories.push_back( "/Library/Audio/Plug-Ins/LADSPA" );
If you can temporarily move any and all of these and see if it helps load times, that would help narrow down the cause.
I can confirm this bug in Version 1.2.0-rc5 (Linux/x86_64, Qt 5.9.2, GCC 4.8.4) on Linux
Changing the default VST directory which is set to the user home following the hint by @Umcaruje solves the problem.
If that was caused by recursive walk over all subfolders, than, maybe, after some time to ask user: "skip this folder, because it's parsing can take a while" ?
If he answers 'yes' - than just skip that folder.
It's actually worse in my case. I'm waiting TWO MINUTES after klicking Add Effect and nothing happens.
@slawekwaga
Despite me confirming this issue (or similar) earlier in #4200, I just tested this right now and it seems to be working fine for me (with or without moving the /usr/lib/ladspa directory out of the way).
I can see here that the official Debian package was updated in March, so I'm not sure if that changed anything. If it didn't I guess we can assume this was a problem with some external library and not LMMS itself. If that's the case, I suggest rebuilding the AppImage with an up-to-date set of dependencies and letting people here test it out.
Here's the entire changelog, which indicates nothing much has been changed in LMMS itself. The previous update to the lmms Debian package was from December 2016.
lmms (1.1.3-7.1) unstable; urgency=high #
โ
* Non-maintainer upload. โ
โ
[ Javier Serrano Polo ] โ
* Fix build with Clang. โ
* Fix build with GCC 7 (Closes: #853527). โ
โ
[ Boyuan Yang ] โ
* Remove Patrick Winnertz from uploaders list. (Closes: #867759) โ
Thank you for your previous contributions! โ
โ
-- Boyuan Yang <[email protected]> Sat, 10 Mar 2018 11:32:05 +0800
To @musikBear:
Lmms version: 1.2.0-rc5.67
OS: Manjaro 17.1.10 (linux)
Size of queried folders:
I'm having this issue with the AppImage version of LMMS 1.2.0-RC5 and 1.2.0-RC6 on Ubuntu 16.04. I do not have the issue if I compile it from source on my system, but I have Sndio, Carla, and VST disabled ( just because I didn't bother to install them ).
So it is probably a problem with one of AppImage, Sndio, Carla, or VST. I couldn't figure out if you have already determined the problem in the discussion above, but if not, hopefully this helps.
A near-identical problem was reported in #4854, due to a bad default VST path from 1.1.3 making it into the AppImage, which was searching recursively.
This bad default VST path has been blacklisted to avoid this problem. I've uploaded and AppImage for testing available here: https://github.com/LMMS/lmms/issues/4854#issuecomment-471117793. Can you see if it helps?
That worked! I can add effects without problem! :+1:
Closed as duplicate of #4854.