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