Main menu
You are here
qtractor fails to start with too many LV2 plugins
25 July, 2014 - 17:23 — Reuben
For some reason qtractor will no start when there are too many LV2 plugins. The window opens up, but the program stalls and never draws anything in it.
I was thinking that perhaps a plugin was causing it to hang, so I was moving plugins in and out of /usr/lib/lv2 to try to find out which was causing the problem. But I ended up discovering that it wasn't a matter of which plugins, but how many.
Forums:
Re: qtractor fails to start with too many LV2 plugins
The number of plugins you can run depends on the available system resources. Does DSP load max out when you start Qtractor with a lot of plugins? And what kind of plugins are you using? And how many plugins are you using in the project that Qtractor fails to open properly?
re. qtractor fails to start with too many LV2 plugins
and how many LV2 plugins are too much?
qtractor has not inherent limit for the number of plugins to scan; in fact it's libLILV that does the actual scan.
consider building for debug (
./configure --enable-debug) and watch for the list of scanned plugins in the stdout/err (console output) right after the lv2_open() call.hth.
cheers
re. qtractor fails to start with too many LV2 plugins
@AutoStatic: it's not to do with the number of plugins used in a session, but rather when it scans all the LV2 plugins when it first initializes.
@rncbc: You're going to enjoy this... The debug build doesn't exhibit this problem. Only the non-debug build. The limit according to the count provided by lv2ls seems to be 255. One thing that comes to mind is that lilv_world_add_plugin() complains about duplicate plugins in /usr/lib and /usr/lib64 since it scans both, and on a Gentoo system /usr/lib is a symlink to /usr/lib64. Perhaps there is an 8 bit limit somewhere to the total number of that type of error in the non-debug builds?
re. qtractor fails to start with too many LV2 plugins
re. lilv_world_add_plugin() complains about duplicate plugins in /usr/lib and /usr/lib64 since it scans both...
yep that's true and that might just be nailing it; what happens when you set the environment variable LV2_PATH explicitly, like eg.:
LV2_PATH=~/.lv2:/usr/local/lib/lv2:/usr/lib/lv2before qtractor is run. that way it will override the internal default to inlcude the lib64 sub-paths to the LV2 plugin search path on x86_64 builds, that is built-in when LV2_PATH variable is not set or is found empty at run-time.
hth.
cheers
Setting LV2_PATH makes no
Setting LV2_PATH makes no difference. It still scans both /usr/lib and /usr/lib64
re. Setting LV2_PATH makes no...
are you sure you're setting LV2_PATH is a way that is visible by qtractor when it runs?
try it with the following command line, literally, for instance:
LV2_PATH=~/.lv2:/usr/local/lib/lv2:/usr/lib/lv2 qtractorone other suspicion is about the capture standard output into messages being overflown with the duplicate torrent--that should explain why the debug version doesn't hang while the non-debug one does--please try turning off View/Options.../General/Options/Capture standard output and restart.
byee
Sorry for the delay...
Sorry for the delay...
Neither setting the variable explicitly in the same command line, nor export of the variable in the local shell's environment has any effect.
Turning off the option to capture stdout/stderr fixed the probelm
Add new comment