|
|
Probably a QT4/QT5 issue. Is that Ardour5 from ardour.org/download on Linux? What distro? |
|
|
Distro is own, QT5. But in Qtracktor all worked nice. Ardour 5.0.0 from git |
|
|
Right qtractor is QT - so it'll work as long as qtractor is compiled with the same QT version as the plugin. Ardour uses libsuil to bridge QT interfaces, and there is no qt5_in_gtk wrapper, only qt4_in_gtk. http://git.drobilla.net/cgit.cgi/suil.git/tree/src You can get around this by compiling qmidiarp with qt4, maybe. If you're luck and get the QT4 ABI of libsuil to match. But really long term no plugin GUI should use any of the desktop-ui toolkits, gtk/qt/wxwidgets etc are entirely inappropriate for plugin UI and will continue to break whenever the ABI changes. |
|
|
Ehhh ... Agree But synthv1 from rncbc also in QT5, and yet worked in Ardour with own QT5 GUI ;) |
|
|
Probably had no missing symbols, because it used QT4 compatible code. |
|
|
I have the same issue still wiht Ardour 5.12 from official sources under Linux Mint 18.3 with KDE5. QMidiArp / Seq / LFO plugins load and show their GUIs fine in Carla host, but not in Ardour. I can only control them with Generic GUI which unfortunately is not enough, because the custom GUI handles defining patterns. |
|
|
PS: The "Edit" menu item is enabled, clicking it doesn't seem to do anything, but there's an error in the Ardour console: "[ERROR]: failed to instantiate LV2 GUI". I've run "ardour --gdb" and got this when clicking the "Edit" button: suil error: Failed to open module /opt/ardour/lib/libsuil_qt5_in_gtk2.so (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.7' not found (required by /opt/ardour/lib/libsuil_qt5_in_gtk2.so)) |
|
|
I've just installed qt5-default package to make sure I am not missing any libraries. No difference. What is strange is that I have the mentioned library in my system: $ locate libQt5Core.so.5 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 |
|
|
Now on my system GUI works perfectly. As I understand this the problem around libsuil_qt5_in_gtk2.so. It must have something to do with installed Qt libraries in OS |
|
|
It's not fixable on our side. It's been over 6 years that we keep reminding plugin-devs to make plugins self-contained (and not depend on external libs). Mid/long-term we'll drop support for gtk and QT plugin UIs and only support native UIs: X11, Cocoa, HWND (and perhaps wayland). |
|
|
Alright, I'll notify the QMidiArp devs. It's strange for me that it works just fine in Carla though. |
|
|
Selection_999(148).png (171,487 bytes) |
|
|
Now what is super strange to me is that QMidiArp GUI works if I load it inside Carla Rack loaded inside Ardour - I've uploaded a screenshot. |
|
|
This is not strange. Carla process-separates plugins. The plugin as well as its GUI run in a separate process (no conflict between QT4 and QT5 libs). Also Carla does not use libsuil but has dedicated bridges. Furthermore Carla itself is also written QT, so as long as the QT versions match this can work. From Ardour's point-of-view, Carla the plugin is a X11 plugin (Ardour does not see any of QT in its memory-space). Still this adds significant overhead (context switches) and is a workaround at best. |
|
|
Yeah, plus I get the feeling that the QMidiArp GUI doesn't function properly with this workaround in place. I seem to be unable to draw a pattern. |
- Anonymous
