30 Jul
2011
30 Jul
'11
2:53 p.m.
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.
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?
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?
30 Jul
30 Jul
4:49 p.m.
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]
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.
-gabriel
[1] http://lists.lv2plug.in
[2] There's talk of renaming it the Atom extension to something
like "Variant" so that it's easier to understand.
7:03 p.m.
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 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.
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] 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
7:16 p.m.
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
6:55 p.m.
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
4860
days inactive
4860
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
David Robillard -
Gabriel Beddingfield -
Paul Coccoli