LinuxMusicians

rncbc wrote:

glowrak guy wrote:Thanks for working on this. I'll wait til there's an rpm,

you can try my opensuse build service repositories including debian, ubuntu and fedora targets:
http://download.opensuse.org/repositories/home:/rncbc/

hth.
cheers

Tried both suse and fedora 6.5.2 rpms, and neither worked to expose the shelled vsts, with dummy on,
segfaulted with no terminal output, whenever a non-shell U-he plugin was added to the path:
/home/me/.uhe/ACE
/home/me/.u-he/filterscape

Worked as before, with only filterscape, uhbiks and zebra paths enabled,
and dummy off, all the shelled plugins appeared for selction, and worked.
With dummy on, all plugins work, but none of the shelled plugins are exposed for selection.
I was careful to reboot, delete old config file etc. Also tried the installers default path again,
and the links from the plugin folders in .u-he to .vst still are not recognized.
Cheers.

glowrak guy wrote:Tried both suse and fedora 6.5.2 rpms, and neither worked to expose the shelled vsts, with dummy on,
segfaulted with no terminal output, whenever a non-shell U-he plugin was added to the path:
/home/me/.uhe/ACE
/home/me/.u-he/filterscape

Worked as before, with only filterscape, uhbiks and zebra paths enabled,
and dummy off, all the shelled plugins appeared for selction, and worked.
With dummy on, all plugins work, but none of the shelled plugins are exposed for selection.
I was careful to reboot, delete old config file etc.

yep. all is working (and not) as reported before. yoy only get vst-shelled sub-plugins listed for selection when "dummy vst scan" is off. but when on that mode you'll get segfault crashes when scanning some non-shelled plugins on the search path... i gave you the example of Diva, but others may be ill-behaved just as bad.

as said, those plugins don't play well on inventory scan, where it actually open/loads the .so and goes through the vst-main procedure to read its meta-information and actual controls and iterate through vst-shell plugin ids, etc. it follows that to continue with the discovery/inventory process the plugin .so will get immediately closed/unloaded and proceed to next .so file in search. some plugins just go nasty with this quick open/close procedure--probably they expect the instance to live on as if it would run for real. dang.

otoh. the "dummy vst scan" is a simple directory file scan: if a file entry has the executable bit on and is a library (.so) then it's assumed to be a VST plugin and fake attributes apply (2 channels for audio i/o, 1 midi in, you get the idea). it's only when you select the entry it gets to actual load and run as real VST plugin.

glowrak guy wrote:Also tried the installers default path again,
and the links from the plugin folders in .u-he to .vst still are not recognized.

the default search path includes "~/.vst" and v0.6.5.2+ should scan into the existing "u-he" sub-directory and anything else for looking for plugin.so's (even though they're symlinks to somethings under ~/.u-he/... well, it works here as advertised, but probably that's not strange to you. :S

thanks for taking the time.
hope to get back soon on this and churn some workaround for this mess--maybe presenting a secondary selection list, if the primary selected one is a vst-shell plugin, or something like that...
cheers

Another twist, new, I think, If I start filterscape first, I can then load zebra and zebralette.
But if I attemp to load zebra first, then zebralette, or zebralette first, then zebra, qtractor
hangs, or vanishes with a segfault.

If I have filterscape, zebra, zebralette, and add another zebra, it also hung.
So perhaps an issue between components of the same shell exists?
Cheers
edit: I loaded Zebra, three Uhbiks, and then zebralette, and it worked,,, yet another scenario.

glowrak guy wrote:Another twist, new, I think, If I start filterscape first, I can then load zebra and zebralette.
But if I attemp to load zebra first, then zebralette, or zebralette first, then zebra, qtractor
hangs, or vanishes with a segfault.

If I have filterscape, zebra, zebralette, and add another zebra, it also hung.
So perhaps an issue between components of the same shell exists?
Cheers
edit: I loaded Zebra, three Uhbiks, and then zebralette, and it worked,,, yet another scenario.

do you have, possibly under ~/.vst/u-he/, any other link but just zebra, uhbik or filterscape? if some other non-shell plugin is there found (eg. diva) things will go wary, i've told you before. hangs or crashes happen non-deterministicaly and are kind of an after-effect--they don't always happen at the moment the culprit is scanned, it usually takes a couple of seconds to hit the crap, probably due on dangling pointer mem-faults from a plugin.so that has been already unloaded...

i've been trying your scenarios and some more with only zebra, uhbik and filterscape installed (resp. symlinks under ~/.vst/u-he) and still "eager" to get it hang or crash maybe i'm just lucky.

thanks again for your patience
cheers

retested several scenarios, hopefully this will be a readable format.

.vst folder contains only the u-he links folder.
qtractor path contains
.vst
.u-he
dummy on, scans the plugins AND the links, so two of each, 22 plugins
but vst-shells not expanded

qtractor path contains
.vst
.u-he
dummy off
crash-vanish at load plugin panel

qtractor path contains
.u-he
dummy off
crash-vanish at load plugin panel

qtractor path contains
.u-he/Zebra2
.u-he/Uhbik
.u-he/Filterscape
dummy off
expands vst-shells, scans 16 plugins, 8 uhbiks, 4 zebra,
3 filterscape, and runciter
If I load zebralette on midi track 1
loading Zebra2 on midi track 2 hangs qtractor.
(I noticed in bitwig demo, a similar thing happens, loading
zebralette first, zebra fails to load on a second track,
but a reload attempt requestor appears, and using it is successful.
So there could be a u-he bug in here)

qtractor path contains
.u-he/Zebra2
.u-he/Uhbik
.u-he/Filterscape
dummy on
Only Filterscape Uhbik, and Zebra2 are scanned
(qjackctl still shows the crashed qtractor in the
connection panel but the new one works)

qtractor path contains all 11 plugins in .u-he
dummy off
crash-vanish at load plugin panel

qtractor path contains all 11 plugins in .u-he
dummy on
All eleven plugins appear, vst-shells not expanded
------------------------------------------------------------
Plugins generally worked as expected in most cases.
Cheers

glowrak guy wrote:retested several scenarios...

thanks for keeping up with all this.. trouble.

you know, dealing with closed-source stuff is far from being my cup of tea... :/

whatever

even though, i've taken some drastic measures and have cut all the cruft from qtractor VST interface, explicitly related to X11 and such.

that probably means that some ancient linux-native VST's will stop to work properly. alas. my greatest fear is that the linuxdsp ones will get broken somehow...

meanwhile, would you test it all over again? now with todays git head aka. qtractor v0.6.5.4+ ? it shall appear in the obs repos in a few minutes (as qtractor-0.6.5.4git.dcf2ea), so please take your time and relax

thanks again.
cheers

The new version worked really well on the nouveau Bodhi/ubuntu setup, so it should be
rock solid on the official nvidia setup. Will check tomorrow. Don't fret too much about closed source,
you never know when the Cubase or Pro-Tools
$head-hunter$ may be watching
Anyway, here's some results:

path = /home/me/.vst
.vst folder contains folders u-he and Discovery Pro, and a dozen newer individual native vsts,
TAL, Dexed, JackAss, Obxd etc

dummy OFF

Discovery Pro, all u-he plugins, including the three shelled plugins are all scanned and listed.
But none of one of the other individual plugins. By design? Anyway, great results as a whole.
Only Hive had major issues, and Diva a fairly minor one.

Loaded Discovery Pro on midi track 1

Loaded FilterscapeVA and Uhbik-D on midi track 2

Loaded Zebralette and MFM2 on midi track 3

Loaded Zebra2 on midi track 4
played well...even on my dinosaur computer Pretty awesome update, in my book.
-------------------------------------------------------------

path = /home/me/.vst
.vst contains folders u-he and Discovery Pro, and the individual native vsts,
TAL, Dexed, JackAss, Obxd etc

dummy ON (for the rest of these notes)

All the 11 u-he plugins, and Discovery pro scanned and listed,
the three shelled vsts were not expanded. None of the others appeared.

Loaded Bazille and Satin on midi track 1
Played well
----------------------------------------

Load Diva on midi track 1, crash-vanish

restart, load ACE and Presswerk on midi track 1
played well
load Diva on midi track2
played well, minimize/maximize Diva gui = crash-vanish

restart, repeat previous test:
load ACE on midi track 1, load Diva on midi track 2,
played well, but/minimize/maximize Diva gui = crash-vanish
--------------------------------------------------------------
Loaded Hive and unexpanded Filterscape effect on midi track 1
Hive had sluggish and incomplete screen drawing,
leaving behind rectangular black areas
---------------------------------------------------------
Loaded Podolski and unexpanded Uhbik on midi track 1
played well. Added Hive on track 2, with similar sluggish
and incomplete screen drawing.
-------------------------------------------------------------
Loaded Discovery Pro on midi track 1
Loaded Zebra2 on mid track 2
played well
--------------------------------------------------------
Cheers

glowrak guy wrote:The new version worked really well on the nouveau Bodhi/ubuntu setup, so it should be
rock solid on the official nvidia setup. Will check tomorrow. Don't fret too much about closed source,
you never know when the Cubase or Pro-Tools $head-hunter$ may be watching

a new update is under way (qtractor-0.6.5.5git.63c107) -- with a regression: the old VST/X11 cruft is back in business;

please check whether the reported GUI sluggishness and/or drawing glitches are mitigated or worse.

thanks again
byee

[EDIT:] i am sorry. the changes that seemed to work really well had to be reverted--latest snapshot is now qtractor-0.6.5.5git.8a3335.

it was all a silent but terrible mistake. sorry again. trouble was loading all and any plugin.so into memory and never unloading it after, piling up system memory (ram) and only freed when unloaded on exit(); so you were hosing the qtractor address-space with all ladspa, dssi, vst (but not lv2, as they are loaded independently from inventory/discovery)

all this mess shed some more light that there are some VSTs, including some from u-he, that behave badly when their .so is unloaded (one example, as i would repeat myself once again, is Diva, but other might choke quite as bad...).

bad news are that we have just gone back to square one; good news are, it is not zero.
thank you.

"so you were hosing the qtractor address-space with all ladspa, dssi, vst (but not lv2, as they are loaded independently "
(in the following, ladspa and LV2 folders were used both normally, and then renamed, to hide them,
didn't seem to make a difference.)

qtractor 0.6.5.5git.8a3335

First, the mixed, and good news...

dummy OFF
path /home/me/.u-he/Filterscape
path /home/me/.u-he/Uhbik
path /home/me/.u-he/Zebra2
Ladspa/LV2 folders active
Shell plugins expand, and work well
Filterscape with ZRev on track 1
Zebralette and Uhbik-D on track 2
Loading Zebra2 on track 3 hung qtractor

Repeated, same result

Repeated, again, except with Zebra2 loaded first,
then Zebralette. No hang! (In bitwig, I have noticed a similar
issue of problems when Zebralette was loaded
before Zebra2, mentioned earlier I think)

...if I turn dummy ON and run the same test again,
the shell plugins are unexpanded, listing
2 each of the three shell-plugins
----------------------
----------------------

Next come the not-so-happy-meals, but some
important issues reveal themselves,
a good thing.
-------------------------------------------
dummy ON
path /home/me/.vst
all eleven u-he plugins scan, but unexpanded.
Only Tonespace among the misc linux vsts scans.
Removing tonespace using track properties, erases it's gui screen,
but leaves behind the background, and hangs qtractor.
With Hive on Two midi tracks, played well, but crash-vanish
when using the remove-plugin option in track properties.
--------------------------------------------------------

dummy ON
path /home/me/.u-he
all eleven u-he plugins scan (twice, 32 and 64 bit), but unexpanded.
With Zebra2 and Diva on two midi tracks, played well,
removing Diva on track 2, produces the same crash-vanish
--------------------------------------------------------

dummy ON
path /home/me/.u-he/ 'all individual folders'
all eleven u-he plugins scan (twice, 32 and 64 bit), but unexpanded.
With Diva on one midi track, played well
removing Diva on track 1, produces the same crash-vanish,
same crash-vanish removing single instances of Podolski and Hive.
-------------------------------------------------------------------
dummy off
path /home/me/.u-he/ 'all individual folders'
crash-vanish at load plugin page.
-----------------------------------------------
dummy OFF
path /home/me/.vst
crash-vanish at load plugin page.
removed individual linux vsts, same crash-vanish
loading a u-he plugin.
----------------------------------------
dummy OFF
path /home/me/.u-he
same crash-vanish at load plugin page.
------------------------------------------
dummy ON
path /home/me/.vst
no individual linux vsts
load Zebra2 on midi track 1
minimize maximize OK
crash-vanish at remove plugin page.
-----------------------------------

Hang in there. I'm keeping 0.6.5.4, changing my name to Rio,
and selling it on the black market!

glowrak guy wrote:"so you were hosing the qtractor address-space with all ladspa, dssi, vst (but not lv2, as they are loaded independently "
(in the following, ladspa and LV2 folders were used both normally, and then renamed, to hide them,
didn't seem to make a difference.)
[...]
Hang in there. I'm keeping 0.6.5.4, changing my name to Rio,
and selling it on the black market!

the so called "hosing" pertains to the fact that v0.6.5.4 will keep all and any scanned plugin.so loaded in memory; that means that if you ever scan for LADSPA plugins, they will ALL stay in memory, after that moment; same with DSSI. and VST. so every plugin.so that may be ever found across the respective search paths, if you ever try to scan for them. now, this is unacceptable behavior so the regression was due. sorry for that.

also, most of the crash-vanishing you report are being caused by some or more VST that doesn't cope well with it being unloaded (note that it often occurs when you remove it or start a new session; and on v0.6.5.5 it would certainly happen when you ever exit qtractor).

byee

[UPDATE:] ok. a special hack for all VSTs with own GUI is in effect, starting from qtractor-0.6.5.6git.3cfe31... the hack prevents explicit unloading of all those plugin.so (but only the VST with a GUI). this is more of a mitigation than a real fix: crashes will still happen occasionally, most predictable on session close and/or application exit. :S

To avoid loading vst plugins during program startup, I've hardcoded a list of known non-shell plugins (i.e. the list of my own vst plugins):
(in radium, that is)
But it's not a very good solution.

I've looked a little bit at your code, and do you, by any chance, only scan VST shell plugins when they are opened, and
not during initialization? I think I saw something like that, but maybe I misunderstood. I think that would solve the problem. Another solution
would of course be to store plugin information in a configuration file, and make the user press a "scan" button to rebuild the configuration. I guess the latter is the best solution. If only there was a solution that would not require work.

rncbc wrote:
[UPDATE:] ok. a special hack for all VSTs with own GUI is in effect, starting from qtractor-0.6.5.6git.3cfe31...:S

Tested this on official nVidia 3D, with Filterscape, Uhbiks and Zebra2, in various groups of two or three, and they raised, lowered,
removed, reloaded etc repeatedly, with the caveat that once some of these maneuvers were done, returning to
the plugin list, found it to have reverted to the un-expanded view. But it's another golden brick on
the windy road to perfection.
Cheers

kmatheussen wrote:I've looked a little bit at your code, and do you, by any chance, only scan VST shell plugins when they are opened, and
not during initialization? I think I saw something like that, but maybe I misunderstood. I think that would solve the problem.

qtractor performs the scan only when the user is about to add or insert a new instance a first time, presenting a list of available plugins for selection. the inventory scan results are cached in memory until the user selects another plugin type (LADSPA, DSSI, VST or LV2.

except for LV2, the inventory scan is always performed by scanning the file-system, across plugin search paths¸ for plugin.so's, loading each one (dlopen), read their proper descriptor for parameter and capabilities information (dlsym) and unload (dlclose). then proceed to the next one. however there's this "dummy VST scan" option which just skips all this dangerous load/unload operation when VSTs are about, with fake parameters and capabilities--the case for VST shell sub-plugins is that they won't get ever discovered by this so called "dummy scan".

kmatheussen wrote:Another solution would of course be to store plugin information in a configuration file, and make the user press a "scan" button to rebuild the configuration. I guess the latter is the best solution. If only there was a solution that would not require work.

or the inventory scan / discovery be detached in a separate process, caching that on some innocuous meta-data or configuration file as you suggest. but yeah, always a trade-off between cost (developers) and benefit (users)

cheers

rncbc wrote:

kmatheussen wrote:I've looked a little bit at your code, and do you, by any chance, only scan VST shell plugins when they are opened, and
not during initialization? I think I saw something like that, but maybe I misunderstood. I think that would solve the problem.

qtractor performs the scan only when the user is about to add or insert a new instance a first time, presenting a list of available plugins for selection. the inventory scan results are cached in memory until the user selects another plugin type (LADSPA, DSSI, VST or LV2.

except for LV2, the inventory scan is always performed by scanning the file-system, across plugin search paths¸ for plugin.so's, loading each one (dlopen), read their proper descriptor for parameter and capabilities information (dlsym) and unload (dlclose). then proceed to the next one. however there's this "dummy VST scan" option which just skips all this dangerous load/unload operation when VSTs are about, with fake parameters and capabilities--the case for VST shell sub-plugins is that they won't get ever discovered by this so called "dummy scan".

Oh, well, I was thinking about scanning/populating the vst shell plugins when they are selected the first time. I've just implemented this in radium: http://folk.uio.no/ksvalast/radiumvstshellhandling.mkv Then you don't have to dlopen the plugin during program startup.