[LAD] Question about LV2 UI extension

David Robillard d at drobilla.net
Sat Jul 30 16:55:49 UTC 2011


On Sat, 2011-07-30 at 08:53 -0400, Paul Coccoli wrote:
> I was looking at the (unfinished) example sampler plugin here:
> 
> https://gitorious.org/gabrbedd/lv2-sampler-example

I have moved this to the LV2 SVN repository so it can become one of the
"official examples" (with more functionality than the trivial amp).
This was the original intent (thanks, Gabriel!).  You might want to work
from there:

svn co http://lv2plug.in/repo/trunk/ lv2-svn

The plugin is in plugins/eg-sampler.lv2/

> I ran through the mental exercise of trying to figure out how to
> finish it, and I have a question about the UI extension.  How does a
> UI tell its plugin to load a sample file?  The example has a TODO in
> its run function that indicates it will react to an LV2_Event that
> contains a pathname for a file.  I don't understand how a UI will
> create this event.

That is the big question right now.  I have a pretty clear idea of how
this should work, but there's a bit of a compatibility hang-up with the
event extension...

> On lv2plug.in, I see there's an experimental string-port extension
> that defines a transfer mechanism for strings.  Is this the
> recommended method?  Do any hosts support this extension?

Not really.

> There's also an atom extension, but I don't think I grok it yet.  Can
> I create a port of type atom:MessagePort?  How does a UI make use of
> that?

This is the body of work intended to solve this problem.  Basically it's
exactly the same as events, an "atom" is just an event without a
timestamp.  I was planning to use an "Object" (terminology here in
general could probably use revision.  "Dict"?  "Resource"?  "Map"?)

http://lv2plug.in/ns/ext/atom/#Object
http://lv2plug.in/ns/doc/html/structLV2__Object.html

(forgive the still a bit too obtuse documentation, work in progress)

which is essentially a dictionary (with URI-int keys)

This is sort of a biggish task that depends on things that aren't quite
there, but if you would like to tackle it, awesome.

There are helper functions in atom-helpers.h intended to make building
and using "objects" simple:

http://lv2plug.in/ns/ext/atom/atom-helpers.h

lv2_atom_append_property to build, and lv2_object_query or the iterator
stuff to read it.

I was planning to tackle this myself a few weeks ago, but life got in
the way :/  Regardless, feedback on this general plan would be useful.

The idea is essentially this:

* "atoms" (which should be called "variants") provide a simple
type-tagged container so we can pass around integers, floats, samples,
dictionaries, images, whatever (it is extensible, naturally)

* We need a "message" type for higher level plugin control like "load
this file"

* For a slew of reasons, after considering/attempting several other
options, I've decided that using a dictionary for this is best (sort of
a JSONish concept that works nicely).  The keys of this dictionary are
URIs (mapped to integers for performance), the values are anything
(atoms).  This conveniently meshes with other LV2 technology, e.g. you
can trivially serialise this to Turtle, which is an important quality
since we need to describe this stuff.

Assume an appropriate message does not yet exist (to highlight the
extensibility and ease of doing whatever you need to do).  So,
independent developer, you need a load file message.  Define one:  "A
message with rdf:type = http://example.org/LoadMessage has the mandatory
key http://example.org/filename with a string value, and signifies that
the plugin should load the given filename"

The logistics of moving such messages around and whatnot are identical
to events (though we are going to want to define a non-realtime context
way to handle messages one at a time eventually).

There is a slightly more generic way of approaching this, but that is in
the domain of what message types we define, so I'll avoid that.
Reactions on the general feel of this solution most welcome.  I can
describe the rationalisation in more detail if desired, it's long been
an open question but I feel this solution is very promising.

Cheers,

-dr

P.S. All that aside, writing a UI that doesn't actually work yet for the
sampler plugin would certainly be useful and make it much simpler for me
or whoever else to plug in the message stuff




More information about the Linux-audio-dev mailing list