[LAD] Question about LV2 UI extension

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


On Sat, 2011-07-30 at 09:49 -0500, Gabriel Beddingfield wrote:
> Hi Paul,
> 
> On 07/30/2011 07:53 AM, Paul Coccoli wrote:
> > I was looking at the (unfinished) example sampler plugin here:
> >
> > https://gitorious.org/gabrbedd/lv2-sampler-example
> >
> > 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.
> 
> First, this discussion belongs on the LV2 mailing list.  :-)  In fact, 
> we've been discussing it recently.  See [1]

I have sort of been wondering about that.  Obviously having an LV2
specific list is great when... well, you want to follow LV2 development,
but it also contributes to this vibe of "what the heck is going on with
LV2?"

I would suggest maybe just discussing all this stuff here if it weren't
for the archives.  Having an archive of just the LV2 stuff is very
valuable.  Oh well.

> Second, the current intention is to send an Event with a URL to load a 
> sample file (whether the event comes from a UI or another plugin or 
> whatever).  In order to accomplish this, a standard event type has to be 
> created.  That's what the "Atom extension"[2] -- it's like a standard 
> library of event types.
> 
> HOWEVER, stepping back a little bit, in you could create your own 
> private event type and send it over an Event port.

Right, this is essentially the same idea.  It will work for now, the
problem is that we'll get a million little event types, which is a
problem for numerous reasons.  One of the biggest ones is serialisation.

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.

-dr





More information about the Linux-audio-dev mailing list