0.8.6 and 0.9.8 both give same output error
suil error: Unable to open UI library /usr/lib/lv2/samplv1.lv2/samplv1_ui.so (/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: undefined symbol: hb_font_funcs_set_nominal_glyph_func)
which lv2 host is that? if ardour5.12 then you're busted ;) ie. the ardour build is way too old for
the new matter at hand.
try loading samplv1 under jalv or qtractor, and if they work alright please do file a complaint to ardour.org for making it a build that includes a more recent compliance to harfbuzz, or you can build ardour your self perhaps (it will work that way i'm sure;))
cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, it does load in qtractor... I will contact the ardour folks
thanks
--
Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com
6 Sep 2019, 15:36 by rncbc@users.sourceforge.net:
which lv2 host is that? if ardour5.12 then you're busted ;) ie. the ardour build is way too old for
the new matter at hand.
try loading samplv1 under jalv or qtractor, and if they work alright please do file a complaint to ardour.org for making it a build that includes a more recent compliance to harfbuzz, or you can build ardour your self perhaps (it will work that way i'm sure;))
cheers
Milestone:> git_head
Created:> Fri Sep 06, 2019 05:19 PM UTC by scott
Last Updated:> Fri Sep 06, 2019 05:19 PM UTC
Owner:> nobody
0.8.6 and 0.9.8 both give same output error
suil error: Unable to open UI library /usr/lib/lv2/samplv1.lv2/samplv1_ui.so (/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: undefined symbol: hb_font_funcs_set_nominal_glyph_func)
I reported on the thread of ardour's tracker, a similar issue like this has been occuring since there was some change with one of the libraries..
Are you familiar with this issue-->>
"the line where it reads (for instance, in drumkv1.ttl):
lv2ui:ui drumkv1_lv2:ui, drumkv1_lv2:ui_x11, drumkv1_lv2:ui_external ;
just remove the "drumkv1_lv2:ui, " particle so that line reads like this, thereafter:
which lv2 host is that? if ardour5.12 then you're busted ;) ie. the ardour build is way too old for
the new matter at hand.
try loading samplv1 under jalv or qtractor, and if they work alright please do file a complaint to ardour.org for making it a build that includes a more recent compliance to harfbuzz, or you can build ardour your self perhaps (it will work that way i'm sure;))
cheers
Milestone:> git_head
Created:> Fri Sep 06, 2019 05:19 PM UTC by scott
Last Updated:> Fri Sep 06, 2019 05:19 PM UTC
Owner:> nobody
0.8.6 and 0.9.8 both give same output error
suil error: Unable to open UI library /usr/lib/lv2/samplv1.lv2/samplv1_ui.so (/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: undefined symbol: hb_font_funcs_set_nominal_glyph_func)
Milestone:> git_head
Created:> Fri Sep 06, 2019 05:19 PM UTC by scott
Last Updated:> Fri Sep 06, 2019 07:36 PM UTC
Owner:> nobody
0.8.6 and 0.9.8 both give same output error
suil error: Unable to open UI library /usr/lib/lv2/samplv1.lv2/samplv1_ui.so (/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: undefined symbol: hb_font_funcs_set_nominal_glyph_func)
as said on first comment reply, the issue relates to the harfbuzz library API, for which ardour has long ago taken an old version of it, possibly due on other time and place of build, and the one that Qt5Gui is requesting as of now.
there's strong evidence or suspicions that this breakage trouble happens most probably on later ubuntu (>= 18.04 LTS) and debian (>= 10), meaning later than the former ardour5.12 package build you have.
the other issue you refer to drumkv1, has nothing to do with this. it is an old issue and has been already solved since libSUIL>= 0.10.2.
byee
Last edit: Rui Nuno Capela 2019-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ardour's response to this is pointing the finger to libraries that enable plugins to see each other and that they won't fix it and instead let plugin authors to remedy this. Your plugin does not work with the latest ardour builds, so just letting you know that more users are likely to face the same. The reference to the drumkv1 workaround was an example reference pointed by ardour developers (back on a post that I also tried with your plugin). Possibly with the right manifest your plugin works, but you think the problem is with ardour developers. Here is not a user issue at all. I've compiled 0.9.8 myself, and it still crashes ardour, I spoke about this with ardour and they said they won't fix it. Now I'll be looking into AVLinux to see if they use different manifests or libraries than the system I am currently using because you think the problem is the end-user. I'm here to tell you that the problem is not me or my system, ... Maybe Ardour has a strong development team that understands libraries better than other developers, so maybe you would want to have a discussion with them on why they think it is better not to have plugins talk to one another.
Last edit: scott 2019-09-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
please note that I never said the problem was on the end-user :/
but also it is not on the plugin dev (the plugin works under jalv and qtractor, right?) but it is rather probably an issue of the software eco-system (esp. ubuntu >= 18.04 and/or debian >= 10),
what i'm sure and have confirmed before is that if you compile and build ardour on the target system, having it linked to the same API level of the harfbuzz libraries that libQt5Gui.so also does, the problem goes away.
again, this specific problem has nothing to do with the old drumkv1 .ttl manifest whatsoever; that one has been solved already by libSUIL >= 0.10.2 and is not an issue ever since., unless of course ardour uses the old SUIL modules which don't work; also note that problem was not about crashes in ardour but just about the GUI not showing up properly (gray or black empty window).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The issue at hand is that the plugin relies on a system-wide installed library (libQt5Gui.so.5) wihch in turn needs other libraries, some of which conflict with Ardour.
There are ways to work around this but you're on your own then. It's not reasonable to expect plugins which are not self-contained to work reliably."
^ from their bugtracker
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes, i know that stance from ardour devs. it's their own choice of course, so...
There are ways to work around this but you're on your own
the "your own" here is: even though you can build your own ardour binary from source, as suggested before here and then samplv1 will most probably work right on your system, a proverbial caveat emptor applies: don't expect any help from ardour.org if you find problems, any problems, with any of the so called "non self-contained plugins", (eg. calf, v1's, etc) because you'll get snagged with the very same canned response ;)
cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
actually the calf plugins(0.90.1-2) do work on Ardour6 beta.. they got their act together and got things working like they should, but you on the other hand didn't. ;-) lol
thanks I thinked I learned something from here and the ardour forums
good luck with the plugin, but I'm letting plugin authors know about Ardour6... currently it is like in mix-stage as ardour6 is still in beta and not officially released -- when it becomes released expect a little more traffic for reporting this issue. lol
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Calf is still one of the "non-self-contained" plugins whatever--it's still written on Gtk+ and thus very far from that status--no matter they (the Calf) may now expose as a X11 handle for which all the V1s do also as well, nevertheless.
i'm quite sure you also have several reports of the V1's working fine with ardour5 and 6, just not on some system environment combinations, most specially the Ardour5/6 nighly-builds on Ubuntu18.04+ (bionic) and Debian 10+ (buster) for the exact problem you report: ardour.org seems to build and link on a different, incompatible harfbuzz library codebase, than the rest of the system where its running.
again, if you build ardour5/6 from git on those systems, or ask some distro package maintainer to do so instead, the problem you report goes away. i'm sure i've said that too many times before.
nuff said. thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it would be nice if devs can work together for a common goal because there's just clustering on half-baked solutions when devs start going their own way like this. I'm not pointing the finger at anyone, but just a user perspective -- I mean maybe if there was some kind of Linux-audio alliance community or something you know.. anyways I think I'm going to put a close on this report and I fully appreciate your feedback for this. thanks.
Last edit: scott 2019-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was looking for extra help on understanding how recompiling ardour would fix working with your plugin and I was given some information as to why this may not work as troubling as it may sound -- but I am posting this for information for other users who are in the same boat as I am for understanding why some plugins do not work and why ardour will not fix it. The ardour staff wrote up a new explanation on why plugins do not work and why they will not bother to fix it -- it is more so going with later changes with ardour that I am noticing this. I think there's a lot of reasons why ardour is doing this, but again I am an end-user and not a developer, -- reading through things it sounds like they want users and even plugin developers to be aware of the pitfalls -- it's not that ardour will snagg you if you ask them, they would provide additional information to explain why plugins are not working. The solution you provided to which a lot of time would be needed to recompile ardour is quite an undertaking and users should know whether that would necessarily fix things for them -- not according to the ardour staff -- I sort of relay the things you've told me and I told them that recompiling ought to fix having your plugin work but they say that is a "maybe". Users should not have to recompile projects in order to have your plugin to work. Can you talk to the ardour staff and they can help explain things better. They've been doing this for very long and it may be worthwhile to listen as to why it may not be a bad idea to review some of their suggestions from their point of view as programming a daw is much more difficult than making a plugin for it..
The following is the new post ardour recently created to help explain why some plugins are failing on their platform, and why they consider this a plugin issue and that they will not change code on their side to fixing it. https://ardour.org/plugins-in-process.html
Users should be aware -- developers know their project but there is no finger pointing here -- it's a paradigm ardour has been doing for some time and they are aware why some plugins do not work. Their new post helps clarify some points that users may be searching and that may help to provide some explanation.
hope this helps
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
wouldn't know what to recommend and hope whichever side would ultimately fix the missing piece needed, I am not a developer and just relaying the above message.
thanks
Last edit: scott 2019-09-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
fyi. the new kxstudio repos are now delivering the v1-suite of plugins on a higher rank on the "self-containment madness" as they are all built (on yours truly experiment and advice) to a static build of all the Qt base modules (qtbase-static >= 5.13.1)
that also means with no indirect (lib)harfbuzz references whatsoever. ;)
may you test and live to tell the story
cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
an interesting undertaking thanks.. I am able to install .deb files directly from those kxstudio resources -- however I'd also like to be able to compile from the source but if you may want to check on where it is failing I can provide more detail upon further inspection -- because here I have all dependencies, the ./configure fails after autoconf with something related to pkg_config -- it seems as though there's a problem with the macro definition relating to aclocal..
thanks for getting back to this, your plugins work well with ardour.. so kudos, the people over there are now glad you've taken this step towards "good madness" ;-)
Last edit: scott 2019-10-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ffor you to try the so called "static" build is only possible through the "xstatic" git branch and of course you need to install the custom qtbase5-static package which is only possible from either the new kxstudio repos, from my own PPA's https://launchpad.net/~rncbc or from also my own opensuse build ervice (OBS) project repos https://download.opensuse.org/repositories/home:/rncbc/.
once installed, you must use the following configure spell (this is for my own versions of qtbase5-static, kxstudio«s might be different): ./configure --with-qt=/opt/qtbase5-static/5.13.1 ...
and then proceed to make && make install
as usual.
good luck.
cheers
Last edit: Rui Nuno Capela 2019-10-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
both plugin and standalone run with this compile, thanks for providing a fix for this..
it's been several months since these plugins last worked on this system for ardour and you're helping other users who may be in the same boat..
(pp receipt because you took the time in fixing this :))
good times ahead for opensource :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
which lv2 host is that? if ardour5.12 then you're busted ;) ie. the ardour build is way too old for
the new matter at hand.
try loading samplv1 under jalv or qtractor, and if they work alright please do file a complaint to ardour.org for making it a build that includes a more recent compliance to harfbuzz, or you can build ardour your self perhaps (it will work that way i'm sure;))
cheers
yes, it does load in qtractor... I will contact the ardour folks
thanks
--
Securely sent with Tutanota. Get your own encrypted, ad-free mailbox:
https://tutanota.com
6 Sep 2019, 15:36 by rncbc@users.sourceforge.net:
Related
Tickets:
#15I reported on the thread of ardour's tracker, a similar issue like this has been occuring since there was some change with one of the libraries..
Are you familiar with this issue-->>
"the line where it reads (for instance, in drumkv1.ttl):
lv2ui:ui drumkv1_lv2:ui, drumkv1_lv2:ui_x11, drumkv1_lv2:ui_external ;
just remove the "drumkv1_lv2:ui, " particle so that line reads like this, thereafter:
lv2ui:ui drumkv1_lv2:ui_x11, drumkv1_lv2:ui_external ;"
from https://www.rncbc.org/drupal/node/1918#ardour https://www.rncbc.org/drupal/node/1918#ardour
I'd like to get to the bottom of this, and I think there's a good chance it is affecting other plugins as well..
fwiw, samplv1_jack runs without issues but samplv1-lv2 doesn't..
thanks
--
6 Sep 2019, 16:52 by fmswstl@users.sourceforge.net:
Related
Tickets:
#15as said on first comment reply, the issue relates to the harfbuzz library API, for which ardour has long ago taken an old version of it, possibly due on other time and place of build, and the one that Qt5Gui is requesting as of now.
there's strong evidence or suspicions that this breakage trouble happens most probably on later ubuntu (>= 18.04 LTS) and debian (>= 10), meaning later than the former ardour5.12 package build you have.
the other issue you refer to drumkv1, has nothing to do with this. it is an old issue and has been already solved since libSUIL>= 0.10.2.
byee
Last edit: Rui Nuno Capela 2019-09-06
ardour's response to this is pointing the finger to libraries that enable plugins to see each other and that they won't fix it and instead let plugin authors to remedy this. Your plugin does not work with the latest ardour builds, so just letting you know that more users are likely to face the same. The reference to the drumkv1 workaround was an example reference pointed by ardour developers (back on a post that I also tried with your plugin). Possibly with the right manifest your plugin works, but you think the problem is with ardour developers. Here is not a user issue at all. I've compiled 0.9.8 myself, and it still crashes ardour, I spoke about this with ardour and they said they won't fix it. Now I'll be looking into AVLinux to see if they use different manifests or libraries than the system I am currently using because you think the problem is the end-user. I'm here to tell you that the problem is not me or my system, ... Maybe Ardour has a strong development team that understands libraries better than other developers, so maybe you would want to have a discussion with them on why they think it is better not to have plugins talk to one another.
Last edit: scott 2019-09-07
please note that I never said the problem was on the end-user :/
but also it is not on the plugin dev (the plugin works under jalv and qtractor, right?) but it is rather probably an issue of the software eco-system (esp. ubuntu >= 18.04 and/or debian >= 10),
what i'm sure and have confirmed before is that if you compile and build ardour on the target system, having it linked to the same API level of the harfbuzz libraries that libQt5Gui.so also does, the problem goes away.
again, this specific problem has nothing to do with the old drumkv1 .ttl manifest whatsoever; that one has been solved already by libSUIL >= 0.10.2 and is not an issue ever since., unless of course ardour uses the old SUIL modules which don't work; also note that problem was not about crashes in ardour but just about the GUI not showing up properly (gray or black empty window).
Capela, in case you didn't know I am using Ardour6 the last many months ..
https://discourse.ardour.org/t/samplv1-users-does-it-work-for-you/101617
the above thread was asked last week and is something the ardour developers are not going to fix because it is not regarded as a bug on their side.
It is rather a new paradigm going into Ardour6 that upstream plugins now need to be more self-contained,
https://tracker.ardour.org/view.php?id=7291
"Known issue and won't fix. Arodur will drop support for all plugins that are not self-contained and depend on external libraries.
some background and explanation: http://lists.ardour.org/pipermail/ardour-users-ardour.org/2018-November/028948.html
The issue at hand is that the plugin relies on a system-wide installed library (libQt5Gui.so.5) wihch in turn needs other libraries, some of which conflict with Ardour.
There are ways to work around this but you're on your own then. It's not reasonable to expect plugins which are not self-contained to work reliably."
^ from their bugtracker
yes, i know that stance from ardour devs. it's their own choice of course, so...
the "your own" here is: even though you can build your own ardour binary from source, as suggested before here and then samplv1 will most probably work right on your system, a proverbial caveat emptor applies: don't expect any help from ardour.org if you find problems, any problems, with any of the so called "non self-contained plugins", (eg. calf, v1's, etc) because you'll get snagged with the very same canned response ;)
cheers
actually the calf plugins(0.90.1-2) do work on Ardour6 beta.. they got their act together and got things working like they should, but you on the other hand didn't. ;-) lol
thanks I thinked I learned something from here and the ardour forums
good luck with the plugin, but I'm letting plugin authors know about Ardour6... currently it is like in mix-stage as ardour6 is still in beta and not officially released -- when it becomes released expect a little more traffic for reporting this issue. lol
Calf is still one of the "non-self-contained" plugins whatever--it's still written on Gtk+ and thus very far from that status--no matter they (the Calf) may now expose as a X11 handle for which all the V1s do also as well, nevertheless.
i'm quite sure you also have several reports of the V1's working fine with ardour5 and 6, just not on some system environment combinations, most specially the Ardour5/6 nighly-builds on Ubuntu18.04+ (bionic) and Debian 10+ (buster) for the exact problem you report: ardour.org seems to build and link on a different, incompatible harfbuzz library codebase, than the rest of the system where its running.
again, if you build ardour5/6 from git on those systems, or ask some distro package maintainer to do so instead, the problem you report goes away. i'm sure i've said that too many times before.
nuff said. thanks
it would be nice if devs can work together for a common goal because there's just clustering on half-baked solutions when devs start going their own way like this. I'm not pointing the finger at anyone, but just a user perspective -- I mean maybe if there was some kind of Linux-audio alliance community or something you know.. anyways I think I'm going to put a close on this report and I fully appreciate your feedback for this. thanks.
Last edit: scott 2019-09-15
I was looking for extra help on understanding how recompiling ardour would fix working with your plugin and I was given some information as to why this may not work as troubling as it may sound -- but I am posting this for information for other users who are in the same boat as I am for understanding why some plugins do not work and why ardour will not fix it. The ardour staff wrote up a new explanation on why plugins do not work and why they will not bother to fix it -- it is more so going with later changes with ardour that I am noticing this. I think there's a lot of reasons why ardour is doing this, but again I am an end-user and not a developer, -- reading through things it sounds like they want users and even plugin developers to be aware of the pitfalls -- it's not that ardour will snagg you if you ask them, they would provide additional information to explain why plugins are not working. The solution you provided to which a lot of time would be needed to recompile ardour is quite an undertaking and users should know whether that would necessarily fix things for them -- not according to the ardour staff -- I sort of relay the things you've told me and I told them that recompiling ought to fix having your plugin work but they say that is a "maybe". Users should not have to recompile projects in order to have your plugin to work. Can you talk to the ardour staff and they can help explain things better. They've been doing this for very long and it may be worthwhile to listen as to why it may not be a bad idea to review some of their suggestions from their point of view as programming a daw is much more difficult than making a plugin for it..
The following is the new post ardour recently created to help explain why some plugins are failing on their platform, and why they consider this a plugin issue and that they will not change code on their side to fixing it.
https://ardour.org/plugins-in-process.html
The next link is a discussion thread to show a few concerns and a mention about the problem of using different GTK libraries...
https://discourse.ardour.org/t/ardour6-and-its-broken-plugin-compatibility-checks/101683
Users should be aware -- developers know their project but there is no finger pointing here -- it's a paradigm ardour has been doing for some time and they are aware why some plugins do not work. Their new post helps clarify some points that users may be searching and that may help to provide some explanation.
hope this helps
wouldn't know what to recommend and hope whichever side would ultimately fix the missing piece needed, I am not a developer and just relaying the above message.
thanks
Last edit: scott 2019-09-17
fyi. the new kxstudio repos are now delivering the v1-suite of plugins on a higher rank on the "self-containment madness" as they are all built (on yours truly experiment and advice) to a static build of all the Qt base modules (qtbase-static >= 5.13.1)
that also means with no indirect (lib)harfbuzz references whatsoever. ;)
may you test and live to tell the story
cheers
an interesting undertaking thanks.. I am able to install .deb files directly from those kxstudio resources -- however I'd also like to be able to compile from the source but if you may want to check on where it is failing I can provide more detail upon further inspection -- because here I have all dependencies, the ./configure fails after autoconf with something related to pkg_config -- it seems as though there's a problem with the macro definition relating to aclocal..
thanks for getting back to this, your plugins work well with ardour.. so kudos, the people over there are now glad you've taken this step towards "good madness" ;-)
Last edit: scott 2019-10-03
thanks for testing and feedback
ffor you to try the so called "static" build is only possible through the "
xstatic" git branch and of course you need to install the customqtbase5-staticpackage which is only possible from either the new kxstudio repos, from my own PPA's https://launchpad.net/~rncbc or from also my own opensuse build ervice (OBS) project repos https://download.opensuse.org/repositories/home:/rncbc/.once installed, you must use the following configure spell (this is for my own versions of qtbase5-static, kxstudio«s might be different):
./configure --with-qt=/opt/qtbase5-static/5.13.1...and then proceed to
make && make installas usual.
good luck.
cheers
Last edit: Rui Nuno Capela 2019-10-03
both plugin and standalone run with this compile, thanks for providing a fix for this..
it's been several months since these plugins last worked on this system for ardour and you're helping other users who may be in the same boat..
(pp receipt because you took the time in fixing this :))
good times ahead for opensource :)