On Fri, Dec 07, 2001 at 12:00:02 -0000, Richard W.E. Furse wrote: > GUIS AS PART OF THE PLUGIN
As Paul pointed out it isn't actually neccesary to change LADSPA to implement this. Earlier we we thinking of letting hte plugin specify a UI, but that isn't really neccesary (or desirable). > CATEGORIES > > Again, this is ancilliary to the plugin itself although it did nearly end up > in the original spec. Perhaps we should agree on a set of calls that the > library might support, possibly in a number of different flavours depending > on application requirements. I also like Steve's ontology idea. Well, again this doesn't require any extensions to LADSPA, it could just be a little RDF fragment that can be found from the plugins ID (/usr/share/ladspa/ontology/1220.rdf or whatever). http://www.w3c.org/RDF/ I can see it might seem a bit overkill, but it really is very powerful, and we don't have to use RDF, we could use a simpler representation. > XML FOR PLUGIN PARAMETER SETS > > This is slightly OT but relevant - I think this is a good idea. To do it > "right" it needs to be compatible at least with any spec for networks as any > network standard will have to deal with plugin parameters sets. This will > probably happen anyway - is anyone looking at this? I have a fairly trivial Kai has a ASCII based format for expressing networks, and it is very good, but a bit ecasound specific. > PER-PLUGIN VERSIONING > > Hmmm, not sure about this. PluginID+Version is just a bigger int, so we can > get away with just PluginIDs in principle. I'm not sure versioning helps Yup, I agree. I will try to bump id numbers in plugins that have new interfaces form now on. > CHANGING CONTROL PARAMETERS DURING PROCESSING This has never bitten me because my plugins (nearly) always do: LADSPA_Data gain = *(plugin_data->gain); But this is an important issue and needs to be sorted out. > GOING BEYOND LADSPA > > To quote part of the original posting (see > http://www.ladspa.org/original_api.txt), "I believe this plugin API should > be a subset rather than a superset of the logical functionality of systems > in use at the moment". I still think this is true. The idea was that almost Yep, I agree with this. I was forgetting the S! However I would like to see the defaults (they should be back compatible) and the propsed GUI doesn't add to the complexity of LADSPA. - Steve
