This extension defines an interface that can be used to create UIs for plugins. The UIs are code that reside in shared object files in an LV2 bundle and are referenced in the RDF data using the triples: @prefix pui: <http://lv2plug.in/ns/ext/pui#> . <http://example.org/my-ui> a pui:Gtk2UI ; lv2:appliesTo <http://example.org/my-plugin> ; pui:binary <my-ui.so> . ... where http://example.org/my-plugin is the URI of the plugin, http://example.org/my-ui is the URI of the plugin UI and my-ui.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 and the class MUST be a proper subclass of pui:UI, in this case pui:Gtk2UI. The class defines what type the UI is, e.g. what graphics toolkit it uses. There are no UI classes defined in this extension, those are specified separately (and anyone can define their own). 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. It is also possible to have one UI that works with several different plugins. UIs should also be written in such a way that the host may load several instances of an UI, or different UIs, and use them with the same plugin instance. 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 do 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 the header pui.h is all you can expect to work.
The class which represents an LV2 plugin UI. To be used by a host a UI MUST have at least the following properties: rdf:type (with object a proper subclass of pui:UI) doap:name (one without language tag) lv2:binary (with a shared object file as object) lv2:appliesTo (with a LV2 plugin as object) The rdf:type of an UI is used by the host to decide whether it supports the UI and how to handle the LV2_PUI_Widget object that is returned by the UIs get_widget() function. For example, a type of pui:Gtk2UI might tell the host that LV2_PUI_Widget is a pointer to an object of a type defined in the Gtk+ library. No UI types are defined in this extension, that is intentionally left for other extensions. The doap:name property should be at most a few words in length using title capitalization, e.g. "Flashy Mixer GUI". Use lv2:documentation for more detailed descriptions. UIs may have optional or required features, specified using lv2:optionalFeature or lv2:requiredFeature. The same rules apply here as for plugins; a host MUST pass the LV2_Feature objects for all features it supports to the UI's instantiate() function, a host SHOULD NOT try to instantiate an UI if it doesn't support all of its required features, and an UI MUST fail to instantiate if the host doesn't pass all required features to instantiate(). For details about the C API used to load UIs, see the file pui.h.
A PortProtocol defines a certain way of communicating port data between UI and plugin. PortProtocols can be specified in additional extensions, and those extensions MUST specify: Which plugin port types the buffer type is valid for When the host should call port_event() in LV2_PUI_Descriptor The format of the data in the buffer passed to port_event() The format of the data in the buffer passed to write_port() What happens when the UI calls write_port() in LV2_PUI_Host_Descriptor What data (if any) should be passed in the LV2_Feature data pointer. For an example, see pui:floatControl or pui:floatPeakRMS. PortProtocol is a subclass of lv2:Feature, so UIs use lv2:optionalFeature and lv2:requiredFeature to specify which PortProtocols they want to use.
The rules (see pui:PortProtocol) for this port protocol are: This PortProtocol is valid for ports with the type lv2:ControlPort. The host SHOULD call port_event() as soon as possible when the port value has changed, but the plugin MUST NOT depend on a call for every change or the timing of the calls. However, the host MUST do the calls in the same order that the value changes occur in. The format of the data in the buffer passed to port_event() is a single float, and the buffer size is sizeof(float). Same as 3. The host SHOULD change the port value as soon as possible when write_port() is called, but the UI MUST NOT depend on a change for every call or the timing of the changes. However, the host MUST do the changes in the same order that the function calls occur in. The data pointer in the LV2_Feature object for this feature should be NULL.
This port protocol defines a way for the host to send continuous peak and RMS measurements of the audio signal at a certain port to the UI. The intended use is visualisation, e.g. an animated meter widget that shows the level of the audio input or output. A contiguous sequence of audio samples for which a single peak value and a single RMS value have been computed is called a measurement period. The rules (see pui:PortProtocol) for this port protocol are: This PortProtocol is valid for ports with the type lv2:AudioPort. The host SHOULD call port_event() at regular intervals. The measurement periods used for calls to port_event() for the same port SHOULD be contiguous (i.e. the measurement period for one call should begin right after the end of the measurement period for the previous call ends) unless the UI has removed and re-added the port subscription between those calls. However, UIs MUST NOT depend on either the regularity of the calls or the contiguity of the measurement periods; hosts may change the call rate or skip calls for performance or other reasons. Measurement periods for different calls to port_event() for the same port MUST NOT overlap. The format of the data in the buffer passed to port_event() is a single LV2_PUI_Peak_RMS_Data object, and the buffer size is sizeof(LV2_PUI_Peak_RMS_Data). The UI MUST NOT call write_port() with the ID for this port protocol as the port_protocol parameter. The host MUST ignore any write_port() calls with the ID for this port protocol as the port_protocol parameter. The data pointer in the LV2_Feature object for this feature should be NULL.
This PortProtocol is valid for ports with the type ev:EventPort. The host MUST call port_event() whenever there is an event in an input port prior to the plugin instance's run() function is called, and whenever there is an event in an output port after run() has been called. The UI MUST NOT depend on the timing of the calls. However, the host MUST do the calls in the same order that the events occur in. The host is allowed and encouraged to bundle multiple events into a single port_event() call if it improves performance. The data buffer passed to port_event() is an LV2_Event_Buffer, as specified in the Event extension. The stamp_type MUST be ignored. The frames and subframes fields of every event in the buffer MUST be ignored. Events with type 0 (reference counted events) MUST be ignored. The data buffer passed to write_event() is an LV2_Event_Buffer, as specified in the Event extension. The stamp_type MUST be ignored. The frames and subframes fields of every event in the buffer MUST be ignored. The host MUST NOT pass events with type 0 (references) unless the UI supports the feature "http://lv2plug.in/ns/ext/event". The host MUST pass all the events in the buffer to the plugin instance's event port in the same order, but the plugin and the UI MUST NOT depend on the timing of the events, or on whether they are all sent to the plugin in the same run() call or distributed over multiple calls. The data pointer in the LV2_Feature object for this feature should be NULL.
The class which represents a Gtk+ UI. For a successfully created instance of an UI of this class, the get_widget() function MUST return a pointer to a valid GtkWidget object compatible with Gtk+ version 2.0. The host MUST ensure that the Gtk+ library has been initialised and that the Glib main loop is running before an UI of this type is instantiated. Unless otherwise specified by extensions, all function pointers in LV2_PUI_Descriptor may only be called from the thread that runs the Glib main loop.
This Feature should only be used with UIs. When this Feature is active the host SHOULD NOT resize the UI widget to any other size than its natural size, which the host should be able to determine via the API of whatever toolkit the UI is implemented in. However, the UI MUST NOT break if the widget is resized to another size. This Feature can be used for example when the widget uses a fixed-size pixmap interface. The data pointer in the LV2_Feature object for this Feature should be set to NULL.