ardour vs lv2

I have noticed that the amount of lv2 plugins on my system actually showing in Ardour has drastically diminished.

I am looking for a deeper understanding of why this has to be so -

-what is behind the ‘buffering requirements’ messages in ardour log
-what are/were typical problems caused by lv2 plugins
-are there issues with lv2core vs. lv2-dev
-is there a way to influence ardour blacklisting at my own risk
-are the plugins poorly written
-is lv2 ambiguous as a standard
-does it have design flaws
-is the surrounding system a factor that influences which plugins ardour can sucessfully run
-which variables are
-is Carla (as example for an apparantly very complete lv2 host) compromising resources or stability in order to host many plugins
-does the lv2 standard allow to just deny a plugin gui resources to display i.e. an analyzer without hanging it as a whole
-how can I ‘benchmark’ plugins, learn about resources (memory, dsp, gui rendering…) they’ll be likely to consume
-is there a known reason why ardour4.7 lv2 load/gui load related crashes gave me terminal output pointing to memory allocation errors, or is this too vague to say

I believe it is relatively clear which field of problems I am adressing, of course I enjoy an increased stability, but being forced to give up essential parts of a work environment it has cost time&effort to customize to my needs, is a high price.

I am happy to be referred to places where (aspects of) these problems have been treated, here and elsewhere.

I have noticed that the amount of lv2 plugins on my system actually showing in Ardour has drastically diminished.
Could it be that you have old plugins that don't comply with the latest LV2 requirements? A change was made to liblilv about a year ago which means plugins with invalid .ttl info will no longer load. You can check the plugins with sord_validate as described here: http://lv2plug.in/pages/validating-lv2-data.html

I appreciate the link on troubleshooting (one aspect of) lv2 plugins, so I begin learning, that’s a start.
One next thing I want to check is wether liblilv is among the libraries bundled with ardour, or if the shared library is used.
But I’m afraid that plugins not updated to newest lv2 standards are unlikely to be the root cause, because I’ve (loosely) compared what ardour 3, 4 and 5 show and load on the very same system, and that’s the most recent kxstudio iso, 14.04.5, definitely this years.
If I should name one plugin for a case study, I’d take the much appreciated EQ10Q plugin and its smaller cousins - increasing crashiness as projects fill up on 4.7 (when DSP load is around 50%, and yes, I have tried to use both or only one CPU core), not available on 5.9,5.10 - for me. That’s a popular plugin, so maybe somebody else can say how it works for them.

plugins not updated to newest lv2 standards are unlikely to be the root cause
Did you test any of the plugins that fail to show up with sord_validate as suggested? If not there seems little point asking for help here if you're not going to follow up answers from people who take the time to try and assist.

One thing you maybe need to understand before getting snappy, is that I am living off-grid. This means two things: 1.) when I’m online, I’m not at home and cannot test things straight away, 2.) at home, I still need a lot of patience or a lot of sunshine before I have a precious little bit of energy in my batteries to turn on my laptop for a while.
I have done what I could do in my circumstances, and that’s downloading the sord_validate instructions for offline use.
Until I can perform the suggested check and report results, it might contribute to alleviating my ignorance to illustrate a scenario in which a lv2 plugin would load in one host yes and not in another, wouldn’t they both have to rely on liblilv ?

Unfortunately I possess so little a knowledge in so vast a field that sometimes I have gut feeling as my only advisor. Could this: ardour-4.7.0: malloc.c:2372: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) & ~((2 *(sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long) old_end & pagemask) == 0)’ failed.
be related to the fact thar some devs did see the need to create this : http://kxstudio.linuxaudio.org/ns/lv2ext/rtmempool
, or should I better stop speculating?

Ehem, will I be able to perforn the check at all?

if […]and an LV2 source tree is present…

I do not have the source for the plugins on my box, if that is meant, nor will it be trivial to get it, see last post. I could note the precise debian package name of one set of plugins and if you’re highly motivated, you could perform the check, in that case.
I am sure my kxstudio distro (june 2017) has sord installed, so maybe manpages will help. I am sure I can locate the .ttl file(s) of a given plugin, not so sure what /path/to/lv2-x.y.z is supposed to be for me.
Anyway, I’ll give it a shot when I get home on saturday and have energy for 1h+ , and I’ll be back here

@forestandgarden sorry about the terse reply. Didn’t realise you’re off grid.

A simpler thing to check is the output of the lv2ls command. You can redirect that to a text file, eg.
lv2ls > lv2ls.txt
and look in the text file for messages about ignored plugins.

If you’re using an official binary of Ardour from ardour.org I’d expect it to be bundled with it’s own version of liblilv. This won’t necessarily be the same one used by other LV2 hosts in your distro. You can check what shared system libraries the Ardour binary requires using the ldd command ‘ldd /path/to/binary’. If liblilv is missing from the list shown by ldd it means it’s bundled in. The output of ldd can be very long, so you might need to redirect to a text file, or alternatively use grep to show only lines with the specific library you’re looking for, eg.:
ldd /path/to/binary | grep liblilv

I don’t have access to a computer with LV2 and ardour on at the moment, so maybe someone else can chime in with further suggestions.

I may have misremembered about how to see ignored plugin messages (lv2ls might not show it). A better way may be to start ardour from the command line in an xterm and look at the messages in the terminal.

Oh thanks, and nevermind. I wonder how many people in the world are falling out of the online paradigm. I can assure you that many do not understand that even if I point it out, so if on the side of helpful ardour community members, there’s a waryness to reiterate certain messages, I can relate :slight_smile:

Relieved that this is relaxing…

I have not been home yet, but your suggestions will definitely help if not to solve the problem, then to pinpoint it better - and for me to learn useful things on the way.

best wishes, j

Still no sun, so not many hours on the laptop. What happens is that so far I have not been able to reproduce the situation I had, I see more, but not all, plugins now… My case study candidate loads now, although with varying degrees of crashiness. I have roughly counted how many lv2 plugins show in ardour3.last (shared libs), 4.7, and 5.10 (bundled both), all under 32bit kxstudio 14.04.5 (recent) like the .iso comes, that’s appx. 580 for a3, appx. 430 in a5, and a4 inbetween. To have the three versions installed, I had to override some package ‘conflicts’ settings to avoid having older versions removed automatically, this shouldn’t break anything, but if I’m missing something, let me now. Renaming liblilv and its dependencies into backups within the ardor5 bundle, so as to force the use of shared libraries, added a few, but not many more plugins. I tested loading a few plugins that still didn’t show, in carla, that worked, and since there is the option to run carla host as a lv2 plugin itself, I have a workaround, albeit a somewhat cpu-expensive one.
I could not run sord_validate, since I still do not understand how to pass it a ‘lv2 source tree’ to validate against, lv2ls is not installed by default with the lv2 framework anymore, but I do have lv2validate, which did show an error in the gxtuner plugin, but did validate others that a5 won’t show neither with its own nor the systems liblilv, i.e. the tuners from x42 (Robin Gareus) as compiled&packaged for my distro.

Renaming liblilv and its dependencies into backups within the ardor5 bundle, so as to force the use of shared libraries
What do you mean by this and how did you do it? If ardour5 is compiled with its own version of liblilv built in I don't see how you could force it to use the shared system liblilv.
lv2ls is not installed by default with the lv2 framework
On Debian based systems lv2ls is split out into the lilv-utils package.

Forcing a build of Ardour from ardour.org to use system-provided (or user-provided) libraries is basically asking for things to go wrong. Please don’t do this. If you want to build your own, go ahead and do so. Messing around with our packages is a really bad idea - there are interlocking patches in different libraries, and specially modified versions of libraries.

@jrigg as far as I can see, in the version of ardour5 I have, liblilv is not compiled in, but placed in /opt/a…/lib/ , and the wrapper script prepends that to the library path. If liblilv isn’t found in the a. bundle, /urs/lib/ and so on will get searched

@paul I am trying to pinpoint a problem, amateur fashion, by.testing/excluding. I believe you could save me some of that by shining some light on the question(s) initially mentioned.
I wonder if ‘messing around’ is the appropiate term here. Because just as easily, modifiying these libraries in the first place could be seen as that.
If I have trouble with a lv2 plugin, liblilv is one potential cause, if it is bundeled/compiled in, I have no way of knowing which version I am dealing with, an information I need to ask for help, and that in normal circumstances would be available through the package management system. If you are patching libraries that others have contributed to the linux audio ecosystem, it must have been to improve them. Do these improvements benefit the community, and are they appreciated by the libraries’ developers? Would a vague hint that you mustn’t expect things to work if you mess with them, be a satisfying answer to you in that case?
I have not expected to make things ‘work’ by temporarily disabling some bundled libraries, I have expected to see what the difference would be. One of the differences was maybe 10% more lv2 plugins getting listed in ardour, and I am just as entitled to want to know why this is so as you are entitled not to want to answer my question.