5 May
2004
5 May
'04
9:36 a.m.
These are just my thoughts and some notes about "LADSPA 2.0", the mail I
sent yesterday was the notes I made in the meeting that everyone agreed
to, so I didn't want to add my personal thoughts.
Mentally prefix everything below with "I think...".
I wasn't particuarly happy with the tone of the meeting report, it was a
bit authoritarian for my tastes, but the LADSPA 1.x discussions weren't
really going anywhere, and we had Paul and Stefan at the conference,
Richard had made his feelings clear and we had a reaonable represenation
from the various user/developer groups, so Paul declared us quorate ;)
The .h file will contain a structure much like the 1.x one, but it will
only have:
* an identifier of some kind (like label/uid, maybe with stronger semantics)
* a port count
* a list of ports (float *'s and types, eg input control port etc.)
The other stuff (names, hints, defaults etc.) will be sotred in an
external metadata file.
The float *'s obviously have to be in the struct as thier a point of
reference, and the port types allow a host that just has the .so file to
be compliant, even if it cant do anything intellignet, or present a UI.
There will be a provided library for handling the metadata format. The
format of the metadata is up for discussion, Ideally it should be
something that is easy to parse so people dont have to use the
ladspa-sepcific library if they dont want to.
The library API will be very thick, eg get_defaults(plugin) returning an
array of default values - that kind of thing - hiding the details of the
metadata format.
The reason for this supprising decision (well, I was supprised) was that
everyone agreed that the current mecahnism where some details about the
plugin are in the struct and some is external is not ideal, and the
prevailing opintion is that external metadata is easier to extend without
complicating the struct. There are lots of general, technical reasons why
external metadata is preferable, but theres not space to go into them
here.
Several people expressed concens about the way that extending the struct
we have now either blocks, or complicates future expansions we might
want.
The reason that LADSPA 2.0 will have no more features (than 1.1 + what we
agreed in the meeting) is to allow it to be defined quickly and easily -
if the fetures set is not up for discussion it should be easier to decide.
There is the option for 2.1 etc. which can add more features once the dust
from 2.0 has settled down.
Things like the VST-LADSPA bridge that can generate plugins on the fly
will need a mechanism that allows the dynamic plugin to squirt metadata
generated dynamically into hte host, through an API. The exact API will
depend on the metadata format.
- Steve