19 Jun
2006
19 Jun
'06
8:05 a.m.
On Mon, Jun 19, 2006 at 07:51:59AM +1000, Jez Kabanov wrote:
hmm, wouldn't that mean you need to code something (or include another
library) to parse all that description language making it difficult for
the host coder, and requires learning of a new language for the plugin
developer. seems much simpler and quicker for a plugin developer and host
developer to use a simple callback.
but the localisation is a good idea, but couldn't be handled via gettext
in the usual manner.
A library to make hosting LV2s easy is in progress and almost finished,
afaik.
seems to me like LV2 has lots of good ideas, but is
shooting itself in the
foot with complexity?
It's rather LADSPA which shot itself in the foot:
With LADSPA, fixed data fields providing information about the plugin (like
the number and type of ports) are inside the plugin binary, resulting in a
number of problems:
* There is lots of tedious, but quite complex code for providing data needed
inside every plugin source.
* The plugin has to be loaded and linked to retrieve any information about it.
* There's no support for internationalisation.
* Adding anything to the static data means breaking binary compatibility.
LV2 separates the static data into RDF files in the easy to hand-write Turtle
syntax. This provides a solution to all of the above problems. By using RDF,
any kind of additional data can be added by plugin authors without
compatibility problems. Thanks to RDF namespacing, anyone can create
extensions under their own namespace. Successful extensions can then later be
made part of the core spec. Strings can be internationalised easily.
---
Thorsten Wilms