Ardour6 and its broken plugin compatibility checks

Installation & Configuration Linux
#1

I know someone is going to tell me to probably post this on the bugtracker, but I am still new to ardour and am not sure of the internal workings of how Ardour checks for invalid plugins

– but today I was trying to look out for incompatible(or known-problematic) plugins in my list and want to know

Do I need to worry that I use gcc4 or gcc5? Users should not have to work at the terminal with ldd commands to check for problematic plugins, when the application’s scan-for-plugins should be doing the full check for this.

I see mention of checking for full compatibility with ldd commands – this is too much baggage to carry for standard users. xd

Eg, searching for “self-contained”(on the forums) and here I am trying the nightly-beta of Ardour6 – I want to be able to effectively avoid repeating falling into the same confusion whether to report a-bug-or-is-it-ardour issue knowing that Ardour6 has been adopting a new paradigm which breaks legacy plugins.

It is not until I add a guitarix plugin to the processor list, and then try to load its gui that I then can spot the red-alert led telling me that the gui failed.

^ Shouldn’t ardour be able to fully determine this prior adding it to the plugin list?

According to the night-build page, there is a mention of problematic plugins
->
“Known affected plugins: abgate , ams-lv2 , amsynth , beatslash , deteriorate , eq10q , guitarix , ingen , midimsg , newtonator , triceratops , vocproc .”

… and I only noticed this a little while later after getting red-alert errors in ardour – so folks why can’t the plugin-check avoid adding problematic plugins when it first sees them?

If a user can determine this with ldd commands, why not include that as part of the plugin-check?

This system of having broken plugins listed can be improved because a user should not have a plugin added that is only known to work “half-way”. Ardour can do better than this.

thanks

#2

A few things:

One this should not be discussed on the forum right now. Ardour6 is not in a state for public testing really, and these sorts of discussions should be in IRC for the most part.

If you are testing Ardour6, you should be able to answer this. It has to do with how software is compiled on your system, and the chances or you changing versions of GCC in the middle of testing should be so slim to never be an issue. If you are mixing precompiled packages you don’t know about, you should probably be comiling your own. Again this is not the standard for most users, but Ardour 6 should only be utilized by people testing at this point, and it is not ready for most people to test so most of the testing should be done by people that are a bit more advanced.

Again A6 is not ready for standard users.

I believe this would require instantiating the plugin and opening the UI in order to do, not an easy task.

How would they be identified? If identified by something like plugin ID, then what happens if they change their plugin id to fix the ‘problem’ or otherwise? What happens if they actually switch to be self contained without changing their plugin ID?

Also important to note that just because it CAN cause problems doesn’t mean it always does for all users. CALF plugins for a long time were a known issue for this (And I believe still are GTK based, and thus not really self-contained) but for many users they work fine. While I still don’t recommend them myself, does this mean that they should stop working for those users?

And here is the other thing, I play devil’s advocate in this to get you thinking more than anything, but again I am going to strongly suggest this conversation goes to IRC instead of the forums at this time.

  Seablade
1 Like
#3

There’s a bunch of confusion here.

There’s no new “Ardour 6” changes with respect to plugin compatibility.

The issues with gcc4/5 exist in Ardour 5, and would apply to any plugin host written in C++ that is combined with plugins written in C++. This is not new to Ardour 6. This category of error cannot be detected by the host - it is a deep compiler/linker issue that has nothing to do with the code of either the host (Ardour) or the plugin. It is entirely caused by how the host/plugin is built, and differences between the process for each.

The issues with plugins using certain desktop GUI toolkits that are incompatible with a given Ardour build are also not new, but they have surfaced more in the last few years as a few notable plugins have been written using Qt or GTK3. It also comes up more now that the current version of such toolkits have been around for a long time.

We have started stating more clearly that we (like every other plugin host) expect plugins to be self contained, but that’s not a new requirement.

As Seablade noted, our plugin scanner checks the core plugin functionality but does not attempt to instantiate the plugin GUI. That would be (a) insanely expenseive and (b) incredibly annoying for users. I don’t know of any other plugin host that does this, on any platform. Plugins on Linux have this toolkit problem which doesn’t affect things on other platforms (at least not the same extent).

Finally, as someone relatively new to Ardour, I cannot recommend that you get involved in testing Ardour 6 at this time. We have not even reached alpha release stage yet.

#4

OK. the issue I have is that none of the Ardour5 builds works on Debian’s latest buster 64-bit,

so I resorted to sticking with Ardour6 beta, and numerous vst plugins work without issue, … it is only lv2 plugins that is an issue…

and this was covered on the previous thread made about samplv1-lv2 (so I’m not going to bring it up again)

the author of a third party plugin mentions that using git and recompiling ardour would fix the majority of lv2 compatibility issues on debian, but that alternative at the moment is just not suitable for me…

… but imho it would be at the same not a bad idea to remind that there are daw’s that have plugin-crash protection — I mean just for the “start up”(gui loading) of the plugin so that it doesn’t bring down the rest of the daw with it.

other daws have this crash-proof mechanism… it just imho makes things a little easier

just an opinion piece.

thanks

#5

there’s kind of finger pointing back and forth between some plugin developers with their daw – I just do not want to get into that debate because I don’t program things here.

what I don’t get it is why there can’t be a “simple” mechanism to improve the way plugins are handled – I mean even if recompiling Ardour(as a plugin developer suggested) would fix lv2 compatibility on Debian – there should imho be positive outcome for users who do not have to worry about their daw crashing because one plugin is misbehaving.

It doesn’t matter if I used Ardour5 when I was able to run it back on debian stretch – I did a couple of test runs and it failed to load samplv1-lv2

The occassion of other users reporting success of this same plugin led me to wonder to why it doesn’t work here on Debian. Those other users reporting success for this plugin must be using different builds of Ardour going on Ubuntu.

I was seldomly using Ardour5 a year ago, — going a little more in-depth with Ardour and the latest debian means I am not worrying about trying the most on-edge things.

I just don’t want to use something that is known to be broken and rather be using something that works.

Here the beta for some reason so far has not been causing issues for vst plugins (a few commercial ones as well).

I am still kind of new to Ardour, but not to Linux and I am rather flexibile to coming with workarounds – but recompiling large projects is really not my taste of having 1 or 2 lv2 plugins working on here.

… I was hoping I can get some insight as to what is really going on with the compilation of Ardour for the Debian distribution, because it seems to me a lot of users are saying a group of lv2 plugins work for them on supposedly “Ubuntu”, but completely are not passing at all on Debian.

The upstream plugin developer’s guaranteed solution? -> recompile Ardour.

^ really? If that what it takes to have Ardour working better I might have to look at that next summer, lol

…I just spent time fixing other matters at hand that I am not ready to tackle Ardour-built issues…

thanks

#6

“crash protection” is done by running plugins in another process. This does not scale, for reasons explained here: http://lists.ardour.org/pipermail/ardour-users-ardour.org/2015-August/027373.html

Ardour is not going to do that.

I’m sorry that you’re having the issues you are, but the specific issue of plugins that rely on desktop GUI toolkits that cannot be loaded into Ardour’s address space without causing problems … well, this isn’t going to get fixed.

You might consider running them in another process as some kind of fix … we don’t. We see it as a band-aid/plaster that hides incorrect design/implementation in the plugin (think about it: the plugin developer is effectively saying “you must either use the same toolkit as me, or you must run me in a different process”).

There’s no “simple” way to fix this that doesn’t break something else. You may not care about plugin hosting scaling to “industrial scale” sessions, but we do.

2 Likes
#7

Another note: this is not a guaranteed solution. If the plugin was written to use GTK3, nothing can fix the problem (GTK3 and GTK2 (which Ardour uses) cannot exist in the same address space).

1 Like
#8

thanks for your explanations Paul, I’m beginning to see the bigger picture, it really is a complex subject – your feedback is very much appreciated.

#9

For reference, I’ve added a longer more in-depth explanation of all this stuff, which you can read here: https://ardour.org/plugins-in-process.html

4 Likes
#10

that helped clarify to me about what was being referred to as self-contained plugins. I was under the impression that it meant to be sandboxed and I got lost somewhere in its vernacular definition.

thanks for clearing this up for me …

#11

Suppose we work at about 4 msec of latency by using a 2048 sample buffer size at 48kHz.

I get around 43 msec with a buffer of 2048.

#12

Thanks for the correction. Silly me. I’ve updated the text to reflect reality.

#13

I liked the principle of the previous argument – context switches reduce the available processing power. So you could use :

Suppose we work at about 5 msec of latency by using a 256 sample buffer size at 48kHz.

The previous argument applies. Now the figure is around a 10% reduction (0.5/5.3 = 9.4%)

#14

I’ve updated the math and the argument to fix some mistakes I made.

#15

This is a good article, well written and readable. It makes a good case for why Ardour handles plugins the way it does and clarifies why ‘crash protection’ isn’t desirable for large, low latency projects.