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