This is interesting. While there have been a few changes to LV2 DSP, there are no changes to Ardour’s LV2 GUI or any VST3 related code.
Could you get a backtrace (Debugging Ardour | Ardour DAW) using the nightly?
@SadKo would you have a guess what change since LSP 1.2.29 could cause this?
No problem here with Ardour-9.7.113 (nightly) and Lsp-plugins-1.2.33 (from openSUSE repo) lv2.
Hello!
I have no idea at this moment. I’ve requested stack traces here but still no feedback:
https://linuxmusicians.com/viewtopic.php?p=185853#p185853
Also I can confirm that I have no issues with Ardour 9.7.112 and build of both 1.2.33 and development versions under openSUSE Leap 16.0.
Vladimir, I just generated a backtrace, hope I did it correct,
I used Ardour-9.7.125-dbg and LSP-plugins-1.2.33.
I’m on Arch, X11, KDE
would like to provide you this 93kb textfile, but cannot succeed here… pls advice,
suse
OK. Now it’s clear. Seems that system FreeType library that LSP Plugins try to load gets into conflict with Ardour’s one. This hack was implemented because Ardour uses rare version of FreeType and thus the rendering of some glyphs was incorrect.
@x42 are you available to update the built-in FreeType library inside of Ardour to at least to 2.11 version since there is a new font rendering engine introduced which fixes this issue between standalone and LV2 format UI differences of plugins inside of Ardour?
The related ticket is here: Horizontal movement of parameter value text when adjusting · Issue #619 · lsp-plugins/lsp-plugins · GitHub
If you update the FreeType library inside of Ardour, I can surely remove this hack in my code for loading the system version of FreeType library.
At the risk of sounding like a broken record:
Plugins must be self contained and not dependent on external libraries.
Just statically link them, since you cannot even be certain that libfreetype is available to begin with. It almost certainly is not on most systems that Ardour runs on.
—
PS. Ardour’s libfreetype is patches to disable byte odes (we think the rendered text looks nicer). You may not want this for your plugins.
@x42
LSP Plugins use FreeType as a system library on Linux and FreeBSD. On Windows there is another way to render custom fonts. For MacOS we also will implement the solution that uses standard system libraries.
The problem here is that libfreetype overrides the system FreeType library because is provided as a shared object inside of Ardour’s environment. Maybe it would be better to use libfreetype as a statically-linked library by Ardour then?
There is stb_truetype, a single header public domain licensed library providing support for custom font loading (No fontconfig no libfreetype). Works well for me. stb/stb_truetype.h at master · nothings/stb · GitHub
so far so good, the specialists exchanged their positions - and what do I do with this? Any advice, any chance for me as a user getting the cow off the ice?
At the risk of sounding like a broken record again…
That doesn’t work when you load multiple plugins. Two different plugins may depend on different versions of libraries. A common example for this is aubio. Debian even ships libaudio.2 and libaubio.3 which are not compatible, dynamically linked plugins broke when they’re loaded in the same memory space.
Until LSP fixes things, you could always pick a different plugins set, or a different DAW that is not affacted 
That doesn’t work when you load multiple plugins. Two different plugins may depend on different versions of libraries. A common example for this is aubio.
Hmm. I supposed that statically-linked library should be linked with -fvisibility=hidden option so plugins won’t see Ardour’s libfreetype library and use the system one. By another way, the clash between versions of other libraries is a serious problem, too. I remember the problems of GTK3 vs GTK2. But I suppose it being a bit different problem because here the Ardour’s freetype library clashes with system one we want to use.
I’ve moved the usage of system FreeType library under the option so users now are responsible for turning this hack on. Changes will be available in the next release.
Indeed. Though Ardour also comes with custom fonts and is self-contained (not unlike flatpak).
A workaround may be to remove Ardour’s bundled libfreetype.so and hope that that the system-wide one is backwards compatible.
Yep, good call! For plugins, I tend to use
CFLAGS += -fvisibility=hidden -fdata-sections -ffunction-sections
LDFLAGS += -fvisibility=hidden -fdata-sections -ffunction-sections -flto -Wl,--gc-sections -Wl,-O1 -Wl,--as-needed -Wl,--strip-all
@x42 the main question about Ardour is, is there any reason why Ardour uses dynamically-linked libfreetype in it’s binaries tree? I suppose it would be a good feature to make libfreetype statically linked for Ardour.
Same reason all other libraries are not statically linked: Manly because that’ll break distro builds of Ardour.
There is a even a config option to do so, but it also results in a huge binary. Besides that’d be Ardour only, there may still be other hosts or other deployment systems (e.g. flatpak version of Ardour)…
PS. x42-plugins do statically link against libfreetype.
Another reason is that static linking is incredibly slow and while I care about users, I link Ardour dozens to hundreds of times per day. While in theory a simple switch for the release builds could work, that exposes us to another set of risks, since the version we’d be using day to day and for development would be linked entirely differently.
Just cloned & built ardour 9.7.276 from git, can confirm everything is working OK with LSP plugins 1.2.33.
Only problem i had was, i needed to remove my session load hook and restore it (scripting window) because it kept retriggering once at each second.