message
type: Specification
name: LV2 Message
maintainer: David Robillard
comment: This extension defines a standard for LV2 "messages" which allow dynamic control and investigation of plugin instances, by both hosts and other plugins. This extension requires the host to support the LV2 URI Map extension, and the LV2 Atom extension.

LV2 Message Type
type: Class
comment: Base class for all types of LV2 Message. A type of message, which must be a resource (i.e. have a URI). This URI is used as the selector component of a Message and is used by receivers to interpret the meaning of messages (e.g. which components are present). A message in memory is simply an atom:Dict with at least one rdf:type that is a rdfs:subClassOf msg:MessageType. The definitions of various message types define what other key/value pairs can be expected in the message.

Control Port
type: Class
subclass of: Port
comment: An input port used to control a plugin instance. A plugin has at most 1 msg:ControlPort. A ControlPort is always an lv2:InputPort. Hosts can send messages to the control port in order to investigate or manipulate a plugin instance (possibly on behalf of a UI or another plugin instance). This is an abstract port class, the actual format and semantics of the port buffer (and messages) are defined by some other port type, i.e. a cmdControlPort MUST have another type which defines the format and semantics of the port buffer contents (likely candidates are atom-port:MessagePort or ev:EventPort).

Response Port
type: Class
subclass of: Port
comment: An output port used to notify the host about changes to a plugin instance or respond to messages send to its msg:ControlPort. A plugin has at most 1 StatusPort. A StatusPort is always an lv2:OutputPort. Any response to a command sent to the CommandPort of the plugin will appear in the StatusPort output. The plugin may also emit other messages (i.e. the contents of a StatusPort are not necessarily responses to commands). This is an abstract port class, the actual format and semantics of the port buffer (and messages) are defined by some other port type, i.e. a cmdControlPort MUST have another type which defines the format and semantics of the port buffer contents (likely candidates are atom-port:MessagePort or ev:EventPort).