View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006268 | ardour | bugs | public | 2015-04-21 12:06 | 2015-04-24 02:58 |
| Reporter | ventosus | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 4.X git (version in description) | ||||
| Summary | 0006268: ui_type is wrongly set for ui_externalkx in LV2Plugin::init | ||||
| Description | 'LV2Plugin.ui_type' is set to '_win.ui_external' instead of '_win.ui_externalkx' in 'LV2Plugin::init'. As a consequence, 'LV2Plugin::c_ui_type' will return a wrong LilvNode pointer. Patch attached | ||||
| Tags | No tags attached. | ||||
| related to | 0006278 | new | allow to choose LV2 GUI (in case plugin provides multiple) |
|
2015-04-21 12:06
|
0001_ui_type.patch (517 bytes)
diff --git a/libs/ardour/lv2_plugin.cc b/libs/ardour/lv2_plugin.cc
index d98f9a9..1ae314c 100644
--- a/libs/ardour/lv2_plugin.cc
+++ b/libs/ardour/lv2_plugin.cc
@@ -592,7 +592,7 @@ LV2Plugin::init(const void* c_plugin, framecnt_t rate)
const LilvUI* ui = lilv_uis_get(uis, i);
if (lilv_ui_is_a(ui, _world.ui_externalkx)) {
_impl->ui = ui;
- _impl->ui_type = _world.ui_external;
+ _impl->ui_type = _world.ui_externalkx;
break;
}
if (lilv_ui_is_a(ui, _world.ui_external)) {
|
|
|
The distinction is ardour internal. suil does not support the KXStudio URI. suil only knows about the "official" LV2 externalUI URI and simply ignores those (they can't be wrapped to begin with). AFAICT the current code is correct with that respect. |
|
|
Is there a specific issue that the patch addresses? I just checked. Both externalUI as well as kxstudio-external UIs do work just fine. |
|
|
with the patch I do get suil error: Unable to wrap UI type <http://kxstudio.sf.net/ns/lv2ext/external-ui#Widget> which is expected (suil has no clue about that). The current (unpatched) code, suil acknowledges http://lv2plug.in/ns/extensions/ui#external and simply ignores it... |
|
|
>> Is there a specific issue that the patch addresses? I thought so, but apparently it does not fix it. Sry for the noise. I'm having issues with an LV2 plugin on OSX which defines both an 'ui:X11UI' and 'kx:Widget' in its turtle. When both are defined, neither GUI is loaded, if I comment out 'ui:X11UI', the 'kx:Widget' UI does load. With further investigations, I think I know what is happening: 'suil_ui_supported' returns 'SUIL_WRAPPING_EMBEDDED' for X11UI plugin in a GtkUI host, even if it cannot embed it (Ardour does not ship with a 'libsuil_x11_in_gtk2.so'). UI discovery code in Ardour thus thinks it has found a valid ui (the X11UI) and does not look further. But in a later step ('suil_instance_new') it will fail to wrap the X11UI as it lacks the corresponding wrapper. I'm not sure whether this should be fixed in Ardour or libsuil directly... Ardour on OSX could provide its own version of 'cocoa_ui_supported' instead of 'suil_ui_supported' returning positive results only for 'GtkUI in GtkUI host' and 'CocoaUI in GtkUI host', e.g. for the wrappers Ardour actually ships on OSX. Possible patch attached, not tested, no access to OSX atm. >> The current (unpatched) code, suil acknowledges http://lv2plug.in/ns/extensions/ui#external [^] and simply ignores it... Yes, I understand and fully agree. Code seems to be fine as it is now. |
|
2015-04-21 20:08
|
0002_cocoa_ui_supported.patch (1,412 bytes)
diff --git a/libs/ardour/lv2_plugin.cc b/libs/ardour/lv2_plugin.cc
index d98f9a9..9dc5048 100644
--- a/libs/ardour/lv2_plugin.cc
+++ b/libs/ardour/lv2_plugin.cc
@@ -231,6 +231,27 @@ log_printf(LV2_Log_Handle handle,
return ret;
}
+#ifdef __APPLE__
+static unsigned
+cocoa_ui_supported(const char* container_type_uri,
+ const char* ui_type_uri)
+{
+ enum {
+ SUIL_WRAPPING_UNSUPPORTED = 0,
+ SUIL_WRAPPING_NATIVE = 1,
+ SUIL_WRAPPING_EMBEDDED = 2
+ };
+ if (!strcmp(container_type_uri, ui_type_uri)) {
+ return SUIL_WRAPPING_NATIVE;
+ } else if ((!strcmp(container_type_uri, LV2_UI__GtkUI)
+ && !strcmp(ui_type_uri, LV2_UI__CocoaUI))) {
+ return SUIL_WRAPPING_EMBEDDED;
+ } else {
+ return SUIL_WRAPPING_UNSUPPORTED;
+ }
+}
+#endif /* __APPLE__ */
+
struct LV2Plugin::Impl {
Impl() : plugin(0), ui(0), ui_type(0), name(0), author(0), instance(0)
, work_iface(0)
@@ -565,7 +586,11 @@ LV2Plugin::init(const void* c_plugin, framecnt_t rate)
const LilvUI* this_ui = lilv_uis_get(uis, u);
const LilvNode* this_ui_type = NULL;
if (lilv_ui_is_supported(this_ui,
+# ifdef __APPLE__
+ cocoa_ui_supported,
+# else
suil_ui_supported,
+# endif /* __APPLE__ */
_world.ui_GtkUI,
&this_ui_type)) {
// TODO: Multiple UI support
|
|
|
On OSX there is no X11, you do indeed want a CocoaUI. Ardour will take no part in this. All LV2 plugin GUIs embedding is handled by suil. libsuil's "Cocoa in Gtk" wrapper works just fine as is. The difference is: KXstudio externalUI enforces the plugin GUI to be re-instantiated every time it is used. The old externalUI allows to keep the GUI around (only show/hide). In any case for new plugin you do want to use the show interface. externalUI goes back to the early days and is on its way out (falktx, kxstudio already moved away kxstudio externalUI for most of the plugins he maintains) see http://lv2plug.in/ns/extensions/ui/#showInterface PS. examples of working LV2/Cocoa plugins: http://x42-plugins.com/x42/setBfree (native CocoaUI) http://x42-plugins.com/x42/x42-meters (kxstudio externalUI) http://harrisonconsoles.com/site/pluginessentials.html (externalUI -- not kxstudio url) |
|
|
>> On OSX there is no X11, you do indeed want a CocoaUI. I can run X11 apps fine on OSX http://xquartz.macosforge.org/landing/ But the problem is not specific to X11UI nor to externalUI, there will be the same issue if a QtUI, WinUI, .. is defined in the turtle. I don't think there is anything wrong if someone ships a plugin with X11UI, GtkUI, QtUI, CocoaUI ... on OSX. It's the host's job to only load what it can show/embed, right? Only that Ardour can't handle X11UI, QtUI, ... on OSX does not mean that another LV2 host will not be able to do so in the future. It can't be that the turtle needs to be adapted to please the hosts capabilities. >> All LV2 plugin GUIs embedding is handled by suil OK, but Ardour should tell suil what it can and cannot embed. By using 'suil_ui_supported' in 'lilv_ui_is_supported', you're telling suil that Ardour can embed EVERYTHING in ANYTHING, which is not true. It will then not search further for a another UI which it actually could show/embed. 'suil_ui_supported' succeedes for all practically possible combinations of GtkUI,QtUI,CocoaUI,X11UI,WinUI,... host-plugin combinations without checking whether the corresponding wrapper has been built. If a plugin on OSX ships a QtUI AND a CocoaUI (even if it's stupid), right now Ardour won't load the CocoaUI because it thinks it can load the QtUI (but it can't, obviously). Is it an issue with libsuil then? Should it be fixed there? >> In any case for new plugin you do want to use the show interface. I'd like to use the showInterface, but neither Ardour nor libsuil seem to implement that extension (correct me if I'm wrong), externalui is the only working fallback. I'm a GNU/Linux dev. I won't write a Cocoa UI. |
|
2015-04-21 21:43
|
instance.c (1,235 bytes)
#define GTK2_UI_URI LV2_UI__GtkUI
#define QT4_UI_URI LV2_UI__Qt4UI
#define X11_UI_URI LV2_UI__X11UI
#define WIN_UI_URI LV2_UI_PREFIX "WindowsUI"
#define COCOA_UI_URI LV2_UI__CocoaUI
SUIL_API
unsigned
suil_ui_supported(const char* container_type_uri,
const char* ui_type_uri)
{
enum {
SUIL_WRAPPING_UNSUPPORTED = 0,
SUIL_WRAPPING_NATIVE = 1,
SUIL_WRAPPING_EMBEDDED = 2
};
if (!strcmp(container_type_uri, ui_type_uri)) {
return SUIL_WRAPPING_NATIVE;
} else if ((!strcmp(container_type_uri, GTK2_UI_URI)
&& !strcmp(ui_type_uri, QT4_UI_URI))
|| (!strcmp(container_type_uri, QT4_UI_URI)
&& !strcmp(ui_type_uri, GTK2_UI_URI))
|| (!strcmp(container_type_uri, GTK2_UI_URI)
&& !strcmp(ui_type_uri, X11_UI_URI))
|| (!strcmp(container_type_uri, GTK2_UI_URI)
&& !strcmp(ui_type_uri, WIN_UI_URI))
|| (!strcmp(container_type_uri, GTK2_UI_URI)
&& !strcmp(ui_type_uri, COCOA_UI_URI))
|| (!strcmp(container_type_uri, QT4_UI_URI)
&& !strcmp(ui_type_uri, X11_UI_URI))) {
return SUIL_WRAPPING_EMBEDDED;
} else {
return SUIL_WRAPPING_UNSUPPORTED;
}
}
|
|
|
attached the function in question from libsuil for clarity. 'suil_ui_supported' |
|
|
OSX does no longer come with a X11 server and it's also no longer officially available from apple these days (there was X11 until 10.6. or so). Ardour on OSX only supports Cocoa Plugin GUIs (32bit versions can also show old carbon UIs). (GTK may work if, and only if, the plugin binary is ABI compatible with GTK that ardour was compiled with, we do not encourage that). There will be no QTUI support, because there's no QT on OSX by default, same for windows. The host (here ardour,suil) only delegate things and never interferes directly. On GNU/Linux it's relatively straight forward: the Linux-distribution provides QT, gtk, X11 and hence can provide a matching libsuil and ardour, ABI compatible with the toolkits. On OSX and windows. Apple and Microsoft set the constraints. If you install xquartz and or QT on OSX, you are also responsible to update suil (and maybe recompile ardour). It's not something we can reasonably support upstream. >> suil_ui_supported' succeedes for all practically possible combinations of GtkUI,QtUI,CocoaUI,X11UI,WinUI,.. if that's true that's a bug in libsuil. I'll check. There's also a feature-reques somewhere to add support to choose the GUI (in case the plugin provides multiple). Currently ardour picks the first available, preferring embeddable over externalUI. >> I'm a GNU/Linux dev. I won't write a Cocoa UI. Easy, then don't bother to provide plugin GUIs for OSX, that you cannot reasonably support. One way out is to use an abstraction e.g. pugl (which supports cocoa, win and X11; and provides a consistent interface on all platforms to the plugin GUI). |
|
|
suil bug report: http://dev.drobilla.net/ticket/1045 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-04-21 12:06 | ventosus | New Issue | |
| 2015-04-21 12:06 | ventosus | File Added: 0001_ui_type.patch | |
| 2015-04-21 18:12 | x42 | Note Added: 0016624 | |
| 2015-04-21 18:14 | x42 | Note Added: 0016625 | |
| 2015-04-21 18:16 | x42 | Note Added: 0016626 | |
| 2015-04-21 20:08 | ventosus | Note Added: 0016627 | |
| 2015-04-21 20:08 | ventosus | File Added: 0002_cocoa_ui_supported.patch | |
| 2015-04-21 20:23 | x42 | Note Added: 0016628 | |
| 2015-04-21 21:31 | ventosus | Note Added: 0016629 | |
| 2015-04-21 21:43 | ventosus | File Added: instance.c | |
| 2015-04-21 21:44 | ventosus | Note Added: 0016630 | |
| 2015-04-22 00:18 | x42 | Note Added: 0016631 | |
| 2015-04-22 00:45 | x42 | Note Added: 0016633 | |
| 2015-04-22 00:45 | x42 | Status | new => closed |
| 2015-04-22 00:45 | x42 | Resolution | open => no change required |
| 2015-04-24 02:58 | x42 | Relationship added | related to 0006278 |
