[LV2] Startup slloowwss dooooowwwwnn???

[hermann meyer]

Am 31.10.2014 11:30, schrieb Stefano D'Angelo:
> 2014-10-28 16:22 GMT+01:00 hermann meyer <brummer- at web.de>:
>> Like most audiophile linux users, sure, I've dssi-vst installed (even 
>> if I didn't use it, I've installed it, play with it for some tests, 
>> and forgot about it, but leave it installed), but, it comes back to 
>> mind when I run into this issue. So, I've already removed it, check 
>> with and without it, didn't helped ether. All, what helps me, is, 
>> remove naspro-bridges. The most annoying behave is, that the single 
>> plugin load gets horrible delayed with naspro-bridges installed, that 
>> seems to me, be related, to a rescan/read/port/bridge/ of all 
>> installed ladspa plugs, at any single plugin load call. May it be, 
>> that lilv search for the plug, when it get called, call naspro, if it 
>> have them, and then naspro looks if it could find, . . . .however, . 
>> . . indeed with dssi-vst this become nearly endless (but, dssi-vst 
>> only rescan the path, if you force that, otherwise it stated 
>> "uptodate"), but as well without, it's unacceptable. I've 
>> installed/remove them several times now, after this report, to test 
>> and check if other circumstances be related, sorry to say, but I cant 
>> find others. Maybe you need to add a uptodate state flag for naspro, 
>> to avoid at least that. 
> It seems to me this is a host-side problem (that I never encountered).
> You could try to compile naspro bridges with --disable-dssi-presets to
> make it less painful, but the problem seems to be in Lilv scanning the
> plugin "world" multiple times, which is weird.
>
> Stefano

Mmm, when you load a plug with jalv, any plug is a single 
(jalv)instance. So, a rescan of the world is expected. Having a "plug" 
like naspro in the path, which takes more then double of the time then 
the hole (LV2)world, is a bit disappointing. Don't get me wrong here, 
the idea in the beginning, to bridge all linux plugin api's, is exiting, 
but, at least, it decrease the useability of LV2 standard here, for me.
Don't you think, you could find a way, to response faster, as I said, a 
"we are up to date flag", like only check if there is a change in the 
search folder, otherwise use a saved config.file to response?

regards
hermann