30 Jul
2011
30 Jul
'11
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