From ed78bbe5ba12be1f9bcc736f14c51da6b4f639f3 Mon Sep 17 00:00:00 2001 From: David Robillard Date: Wed, 8 Feb 2012 04:56:24 +0000 Subject: Rearrange tree so top level can be used as an include path for standard style LV2 includes. --- lv2/ns/ext/pui/pui.ttl | 284 ------------------------------------------------- 1 file changed, 284 deletions(-) delete mode 100644 lv2/ns/ext/pui/pui.ttl (limited to 'lv2/ns/ext/pui/pui.ttl') diff --git a/lv2/ns/ext/pui/pui.ttl b/lv2/ns/ext/pui/pui.ttl deleted file mode 100644 index d305769..0000000 --- a/lv2/ns/ext/pui/pui.ttl +++ /dev/null @@ -1,284 +0,0 @@ -# LV2 Plugin UI Extension -# Copyright (C) 2010-2011 Lars Luthman -# -# Based on lv2.ttl, which is -# Copyright (C) 2006-2008 Steve Harris, David Robillard -# -# This extension should be considered a replacement for the earlier -# in-process UI extension with the URI . -# Hosts and plugins that used that extension should use this one instead. -# The earlier in-process UI extension is not compatible with LV2 revision 3 -# and later and may break in subtle ways. -# -# Permission is hereby granted, free of charge, to any person obtaining a -# copy of this software and associated documentation files (the "Software"), -# to deal in the Software without restriction, including without limitation -# the rights to use, copy, modify, merge, publish, distribute, sublicense, -# and/or sell copies of the Software, and to permit persons to whom the -# Software is furnished to do so, subject to the following conditions: -# -# The above copyright notice and this permission notice shall be included -# in all copies or substantial portions of the Software. -# -# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL -# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR -# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, -# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR -# OTHER DEALINGS IN THE SOFTWARE. - -@prefix doap: . -@prefix foaf: . -@prefix lv2: . -@prefix pui: . -@prefix rdf: . -@prefix rdfs: . - - - a lv2:Specification ; - doap:license ; - doap:name "LV2 UI" ; - doap:shortdesc "Generic UI interface for LV2 plugins." ; - doap:release [ - doap:revision "0.1" ; - doap:created "2011-03-26" - ] ; - doap:maintainer [ - a foaf:Person ; - foaf:name "Lars Luthman" ; - foaf:mbox - ] ; - lv2:documentation """ -

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.

-""" . - -pui:UI - a rdfs:Class ; - rdfs:subClassOf lv2:Feature ; - rdfs:label "UI" ; - lv2:documentation """ -

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. -

-""" . - -pui:PortProtocol - a rdfs:Class ; - rdfs:subClassOf lv2:Feature ; - rdfs:label "Port protocol" ; - lv2:documentation """ -

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: -

- -
    -
  1. Which plugin port types the buffer type is valid for
    2. -
  2. When the host should call port_event() in LV2_PUI_Descriptor
    3. -
  3. The format of the data in the buffer passed to port_event()
    4. -
  4. The format of the data in the buffer passed to write_port()
    5. -
  5. What happens when the UI calls write_port() in LV2_PUI_Host_Descriptor
    6. -
  6. What data (if any) should be passed in the LV2_Feature data pointer.
    7. -
- -

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. -

-""" . - -pui:floatControl - a pui:PortProtocol ; - rdfs:label "Floating point value" ; - lv2:documentation """ -

The rules (see pui:PortProtocol) for this port protocol are:

-
    -
  1. This PortProtocol is valid for ports with the type lv2:ControlPort.
    2. -
  2. 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.
    3. -
  3. The format of the data in the buffer passed to port_event() is a single - float, and the buffer size is sizeof(float).
    4. -
  4. Same as 3.
    5. -
  5. 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.
    6. -
  6. The data pointer in the LV2_Feature object for this feature should be - NULL.
    7. -
-""" . - -pui:floatPeakRMS - a pui:PortProtocol ; - rdfs:label "Peak and RMS for a period of audio data" ; - lv2:documentation """ -

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:

-
    -
  1. This PortProtocol is valid for ports with the type lv2:AudioPort.
    2. -
  2. 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.
    3. -
  3. 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).
    4. -
  4. The UI MUST NOT call write_port() with the ID for this port protocol as - the port_protocol parameter.
    5. -
  5. The host MUST ignore any write_port() calls with the ID for this port - protocol as the port_protocol parameter.
    6. -
  6. The data pointer in the LV2_Feature object for this feature should be - NULL.
    7. -
-""" . - -pui:events - a pui:PortProtocol ; - rdfs:label "Event buffer" ; - lv2:documentation """ -
    -
  1. This PortProtocol is valid for ports with the type ev:EventPort.
    2. -
  2. 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.
    3. -
  3. 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.
    4. -
  4. 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".
    5. -
  5. 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.
    6. -
  6. The data pointer in the LV2_Feature object for this feature should be - NULL.
    7. -
-""" . - -pui:Gtk2UI - a rdfs:Class ; - rdfs:subClassOf pui:UI ; - rdfs:label "Gtk+ UI" ; - lv2:documentation """ -

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.

-""" . - -pui:noHostResize - a lv2:Feature ; - rdfs:label "No host resize" ; - lv2:documentation """ -

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.

-""" . -- cgit v1.2.1