[LAD] Question about LV2 UI extension

David Robillard d at drobilla.net
Sat Jul 30 17:16:06 UTC 2011


On Sat, 2011-07-30 at 13:03 -0400, David Robillard wrote:
> On Sat, 2011-07-30 at 09:49 -0500, Gabriel Beddingfield wrote:
[...]
> > HOWEVER, stepping back a little bit, in you could create your own 
> > private event type and send it over an Event port.
[...]
> It will be much better in the long run to have a very simple data model,
> like "dictionaries and lists" with a generally agreed upon set of atoms
> (int, float, string, etc.) because then hosts just need to implement
> serialisation/understanding/manipulation/persisting/etc of one thing,
> and the higher level semantics (e.g. "this is a load file message" do
> not affect the binary implementation.  In effect, plugin authors (and
> more powerful host *users*) are free to work on their own message
> communication systems without requiring a bunch of C implementation work
> every time somebody needs a new message.
> 
> Personally I think this is very exciting, particularly considering that
> this can easily give us "power user" level messages.  Think Pd/Max built
> on LV2.  The potential for scripting language bindings is also very
> nice, done this way bindings are simple and similarly don't depend on
> the bridge implementing every little binary thing some developer comes
> up with.

On second thought, this is a poor example.  Though the modular heads and
more programmer-user types should get excited, it's a bit nichey.  David
being an ontology astronaut again, y'know... :)

A better example of the user visible win of this is menus, which applies
to virtually any host.  Following the previous example, the plugin would
describe in its data file that it supports the load filename message.
The details of this message (i.e. what keys it has) are also (ideally)
available to the host.

So, the host knows:

* This plugin supports the load-filename message
* The load-filename message needs one property, filename, with a string
key, for which an appropriate label in my locale is "Filename"

So, it can easily build a context menu and/or dialog box for the plugin
that lets the user load a file without requiring a custom plugin UI to
do so.

In other words, a powerful message interface like this doubles as a way
for plugins to provide menu system and/or powerful generic UIs while the
host only has to implement a small core of functionality (i.e. plugins
can add all sorts of messages to mean all sorts of things and since it's
all "dynamic" there is no implementation lag waiting for all the host to
catch up).

As a sidenote, this deliberately meshes perfectly with our concept of
persistent plugin state, which is also based on a similar dictionary:
http://lv2plug.in/ns/ext/persist/

-dr





More information about the Linux-audio-dev mailing list