URI | http://portalmod.com/ns/modgui |
---|---|
Version | 1.0 (2014-10-14) |
Prefixes | dcs doap foaf lv2 mod owl pprops rdf rdfs units |
Discuss | [email protected] (subscribe) |
Developer |
This extension defines a standard for generating web-based interfaces for plugins. Plugins implementing this standard will be compatible with the MOD device and MOD host software.
The goal of this interface is to allow user to have an overview of several connected plugins and quickly access main controls of each one, while still being able to fully configure each one individually, all this in a web-based environment. So, each plugin has two interfaces, one for its Icon and another for the Settings.
The Icon is a representation designed to look like a real device, and will be connected to other plugin icons by cables to make pedalboards. Ideally, each icon will have:
The Settings interface is a panel with all controls of this plugin that can be designed to occupy the whole screen.
To provide this interface for Icon and Settings, the following resources can be used:
Note: The To help the creation of interfaces, several base layouts have been created in the mod-resources project. Some plugins that first implemented the modgui interface will expect the host to provide those resources, and so they may reference media resources that are not packed inside the bundle. Support for those resources is being deprecated, and so any resources required should be packed inside mod:resourcesDirectory.
The web interface definition for this plugin. It's defined by html templates for icon and settings panel, css, images and other media, that's contained in the plugin bundle.
In domain of | mod:iconTemplate |
---|---|
mod:templateData | |
mod:stylesheet | |
mod:resourcesDirectory | |
mod:settingsTemplate | |
mod:thumbnail | |
mod:screenshot | |
In range of | mod:gui |
Relates a plugin to the its MOD Graphical User Interface
OWL Type | Object Property |
---|---|
Domain | lv2:Plugin |
Range | mod:GUI |
A template that will be used to render the HTML icon of this plugin. The value of this property must be a URI that resolves to a Mustache template.
The syntax and guidelines for templates are the same for mod:iconTemplate and mod:settingsTemplate, so this documentation applies to both.
To build the interface, follow these guidelines:
Some elements in your layout are just informative for the user, like the effect name, branding and background img. Others are functional, like the knobs and footswitch. A functional element is marked as so by the "mod-role" attribute, and other mod-* attributes may be used as parameters. The following functional elements may be indicated:
MOD compatible hosts MUST implement a bypass in each plugin loaded. Two elements are responsible for this, the bypass footswitch and bypass light indicator.
The footswitch is an element identified by the mod-role="bypass" attribute. Once clicked, the effect bypass will be turned on or off, and the light indicator will be changed as so.
The light indicator is identified by mod-role="bypass-light". It will automatically receive the class on or off, so designers are expected to implement a background image for each of these classes, or equivalent.
Each plugin can have buttons to control plugin's parameters. Each button is identified by the attribute mod-role="input-control-port" and configured by mod-port-symbol attribute, which must hold the port's symbol, and mod-widget attribute, that defines which widget to use. The available widgets are film, select and custom-select, and each of them expects a certain HTML structure in this element.
The film widget works like a movie film: it uses a big stripe of images and roll it to choose a scene, giving the impression of an animation. So, if you use mod-widget="film", this element is expected to have a background-image style, with one big horizontal sprite as background. User will be able to change that parameter by clicking on the control button and dragging the mouse up or down. As this is done, the background image will be moved to reflect the new state.
The minimum value of that port will be represented by the first position of the sprite and the maximum value by the last one. The number of steps will be calculated by dividing the background width by the element's width, considering the background-size style. The actual number of steps will be the minimum between the number of images in sprite and the steps limited by lv2 definition (by pprops:rangeSteps, lv2:enumeration or lv2:toggled.
For example, suppose you want to build a horizontal slider that can hold 10 different positions occupies an area of 150x30 pixels, to control the drive parameter of your plugin. For that, you could:
The select widget is a simple <select> html element with available options, each one representing one value for this control port. It's mainly intended to be used for ports with the lv2:enumeration property, but can be used for any case in which picking values from a limited set is desired.
So, if you use mod-widget="select", this element is expected to be a <select> and contain several options, each of them must have the value attribute reflecting the float value of this property.
This widget is similar in functionality to select widget, but instead of a select html element holding options, you can choose any element types to represent the widget and the options. If you use mod-role="custom-select", this element is expected to have children elements with the attributes mod-role="enumeration-option" and mod-port-value="(float value)". The selected element will receive the selected class, and so you can define your CSS as to highlight it as desired.
In case you want a list of options to be shown when the widget is clicked, you should mark the element containing the options with mod-widget-property="hidden". When this happens, every click on the widget will toggle that element's visibility.
To allow user to see the minimum, maximum and current value of a plugin, three mod-roles are available: input-control-minimum, input-control-maximum and input-control-value. All of them expect a mod-port-symbol attribute containing the symbol of the port.
The input-control-minimum, input-control-maximum will have have it's text content set to be the formatted minimum and maximum values accepted by this control, as defined by the lv2:minimum and lv2:maximum properties respectively. The input-control-value will be dinamically changed everytime the value of the control port changes.
All values are formatted according to the units:unit's and units:render property of this port, with some considerations. First, any %f will be rendered as %.2f, otherwise interface is messed up with huge representations. Second, if lv2:integer property is declared, then any %f, %.Xf or so will be substituted by %d.
Each plugin has audio input and output ports. They are identified by mod-role="input-control-port" and mod-role="output-control-port" attributes respectively, and both must have a mod-port-symbol property containing the port symbol.
For implementing the connections, each output will receive a <div> element inside, representing a jack (this will be automatically inserted). This jack can be dragged by user and dropped inside an input, and so a connection will be made.
This does not apply to Settings template
Plugins can be dragged around the pedalboard dashboard. To define which area of the plugin can be clicked for dragging, an element with the attribute mod-role="drag-handle" can be defined.
This does not apply to Settings template
Domain | mod:GUI |
---|---|
Range | owl:Thing |
rdfs:seeAlso | http://mustache.github.io/ |
This is a URI that resolves to a directory inside the bundle. Any file inside this directory will be statically served to browser, and will be available at the /resources path.
For the webserver to properly identify where to look, any request for media inside this directory must have an ?bundle=BUNDLE&url;=EFFECT_URL parameter.
Note: using a static url with ?bundle=BUNDLE parameter in any template would be a violation of LV2 Bundle Definition guidelines. So hosts should not require the bundle parameter to load the resources. This parameter is used mostly by the SDK, since speed of reloading for testing interface is an issue there and no bundle index is made. To avoid problems here, always use the {{{ns}}} tag instead of raw urls in your templates and stylesheet, as described in mod:templateData.
Domain | mod:GUI |
---|---|
rdf:label | resources directory |
rdf:range | owl:Thing |
A template that will be used to render the HTML settings panel of this plugin. The value of this property must be a URI that resolves to a Mustache template.
To develop this, use the same guidelines and markup as described in mod:iconTemplate. The only difference is that the audio ports here are irrelevant
Domain | mod:GUI |
---|---|
rdf:label | settings template |
rdf:range | owl:Thing |
A CSS file that holds all styles used for this plugin. The CSS will be automatically loaded on request. For implementation reasons, only one CSS file per effect is supported.
The stylesheet will be parsed for dynamic content, so the {{{ns}}} tag can be used to reference background images and other resources.
Remember that all class names must be preceded by the bundle's name to avoid conflicting with other plugins or general interface.
Domain | mod:GUI |
---|---|
rdf:label | stylesheet |
rdf:range | owl:Thing |
The data that will be used to render the templates defined in mod:iconTemplate and mod:settingsTemplate. The value of this property must be a URI that resolves to a json serialized object and its data can be inspected using the SDK's debug interface.
This parameter isn't strictly necessary to build a plugin layout, as the template can hold the final HTML file, but it's very useful to allow developers to customize layout using templates provided by the SDK, instead of editing HTML files.
The data in this file must be a dictionary. Two keys are automatically set: effect, ns.
This will always hold the effect's data parsed from ttl files. The effect data format is an arbitrary structure that organizes the rdf triples in a simple way. To see that structure, use the SDK's debugging interface
All static files in folder defined by mod:resourcesDirectory will be available to the interface, in path /resources of the webserver. To know where to look, the webserver needs a ?bundle=BUNDLE&url;=EFFECT_URL parameter.
To make this job easier, the ns variable will hold the correct url parameter, so if you want to customize your template (say, have your brand image in the pedal), you can refer to it like this: <img alt="Brand image example" src="/resources/brand.png{{{ns}}}"/>
In the example above, the brand.png file inside the mod:resourcesDirectory would be served
Domain | mod:GUI |
---|---|
rdf:label | template data |
rdf:range | owl:Thing |