[LV2] Startup slloowwss dooooowwwwnn???

[Stefano D'Angelo]

2014-10-31 21:08 GMT+01:00 hermann meyer <brummer- at web.de>:
> 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.

More than double is actually very good for dlopening and scanning all
of the LADSPA/DSSI world. There's no way I can think of to be faster
and stay consistent. If that is too much for you, then you have to
give up this extra compatibility and remove the bridges.

> 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?

That's impossible. There's no guarantee that, e.g., a LADSPA/DSSI
plugin library gives you identical descriptors if it is not updated
(e.g., dssi-vst).

Stefano