@prefix uiext: <http://lv2plug.in/ns/extensions/ui#> . <http://my.plugin> uiext:ui <http://my.pluginui> . <http://my.plugin> a uiext:GtkUI . <http://my.pluginui> uiext:binary <myui.so> .where <http://my.plugin> is the URI of the plugin, <http://my.pluginui> is the URI of the plugin UI and <myui.so> is the relative URI to the shared object file. While it is possible to have the plugin UI and the plugin in the same shared object file it is probably a good idea to keep them separate so that hosts that don't want UIs don't have to load the UI code. A UI MUST specify its class in the RDF data. In this case the class is uiext:GtkUI, which is the only class defined by this extension.
(Note: the prefix above is used throughout this file for the same URI)
It's entirely possible to have multiple UIs for the same plugin, or to have the UI for a plugin in a different bundle from the actual plugin - this way people other than the plugin author can write plugin UIs independently without editing the original plugin bundle.
Note that the process that loads the shared object file containing the UI code and the process that loads the shared object file containing the actual plugin implementation does not have to be the same. There are many valid reasons for having the plugin and the UI in different processes, or even on different machines. This means that you can _not_ use singletons and global variables and expect them to refer to the same objects in the UI and the actual plugin. The function callback interface defined in this header is all you can expect to work.
Since the LV2 specification itself allows for extensions that may add new types of data and configuration parameters that plugin authors may want to control with a UI, this extension allows for meta-extensions that can extend the interface between the UI and the host. These extensions mirror the extensions used for plugins - there are required and optional "features" that you declare in the RDF data for the UI as
<http://my.pluginui> uiext:requiredFeature <http://my.feature> . <http://my.pluginui> uiext:optionalFeature <http://my.feature> .These predicates have the same semantics as lv2:requiredFeature and lv2:optionalFeature - if a UI is declaring a feature as required, the host is NOT allowed to load it unless it supports that feature, and if it does support a feature (required or optional) it MUST pass that feature's URI and any additional data (specified by the meta-extension that defines the feature) to the UI's instantiate() function.
These features may be used to specify how to pass data between the UI and the plugin port buffers - see LV2UI_Write_Function for details.
There are two features defined in this extension that hosts may want to implement:
uiext:makeResident uiext:makeSONameResidentIf the first feature,
uiext:makeResident, is required by a UI the host MUST never unload the shared library containing the UI implementation during the lifetime of the host process (e.g. never calling dlclose() on Linux). This feature may be needed by e.g. a uiext:GtkUI that registers its own Glib types using g_type_register_static() - if it gets unloaded and then loaded again the type registration will break, since there is no way to unregister the types when the library is unloaded.
The second feature,
uiext:makeSONameResident, is ELF specific and if it is required by an UI the UI should also list a number of SO names (shared object names) for libraries that the UI shared object depends on and that may not be unloaded during the lifetime of the host process, using the predicate
uiext:residentSONames, like this:
<http://my.pluginui> uiext:residentSONames "libgtkmm-2.4.so.1", "libfoo.so.0"The host MUST then make sure that the shared libraries with the given ELF SO names are not unloaded when the plugin UI is, but stay loaded during the entire lifetime of the host process. On Linux this can be accomplished by calling dlopen() on the shared library file with that SO name and never calling a matching dlclose(). However, if a plugin UI requires the
uiext:makeSONameResidentfeature, it MUST always be safe for the host to just never unload the shared object containing the UI implementation, i.e. act as if the UI required the
uiext:makeResidentfeature instead. Thus the host only needs to find the shared library files corresponding to the given SO names if it wants to save RAM by unloading the UI shared object file when it is no longer needed.
UIs written to this specification do not need to be threadsafe - the functions defined below may only be called in the same thread as the UI main loop is running in.
Note that this UI extension is NOT a lv2:Feature. There is no way for a plugin to know whether the host that loads it supports UIs or not, and the plugin must ALWAYS work without the UI (although it may be rather useless unless it has been configured using the UI in a previous session).
A UI does not have to be a graphical widget, it could just as well be a server listening for OSC input or an interface to some sort of hardware device, depending on the RDF class of the UI.
Definition in file lv2_ui.h.
|typedef void *||LV2UI_Controller|
|typedef struct _LV2UI_Descriptor||LV2UI_Descriptor|
|typedef const LV2UI_Descriptor *(*||LV2UI_DescriptorFunction )(uint32_t index)|
|typedef void *||LV2UI_Handle|
|typedef void *||LV2UI_Host_Data|
|typedef void *||LV2UI_Widget|
|typedef void(*||LV2UI_Write_Function )(LV2UI_Controller controller, uint32_t port_index, uint32_t buffer_size, uint32_t format, const void *buffer)|
|const LV2UI_Descriptor *||lv2ui_descriptor (uint32_t index)|