Oh dear, here we go again. Richard pops up to be a pain in the neck. The suggestions:
CONTROL PORTS SHOULD ACCEPT ARRAYS This is in the same family as a much more common request, "control ports should accept strings" (or doubles, events, MIDI, WFT etc). This requires a rather more complex API than LADSPA as the API has to handle memory management and more complex port descriptors. This requires a lot more work for the host programmer and is a potential barrier to plugin and host programmer. More in "going beyond LADSPA" below... GUIS AS PART OF THE PLUGIN As I've said before, I'd prefer an approach where an appropriate delivery mechanism can be chosen depending on the toolkit. Flat files may work for XML, or perhaps calls into the library containing the plugin itself. For instance, a host written in GTK might want to look for a "get_LADSPA_gtk_GUI()" in the library containing the plugin. If it finds it, fine. If not, the host might wish to look for an XML wrapper, Snd spec or whatever else it supports. I think it's important that it is possible to separate GUI and plugin (e.g. for remote control of a dedicated FX box). I think work on a number of GUI standards of this type is useful, as long as we can try to get a consensus within each toolkit framework. I'll put archives/links on www.ladspa.org if that's helpful - I think the key to getting this sort of thing to work will be to make everything visible - I *still* don't have a copy of the XML GUI spec! Does anyone implement it yet? 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. 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 but powerful project called PNet that I keep meaning to find time for that would use such files, so I'm very interested in this one (and could produce the spec if necessary). DEFAULT PARAMETER VALUES I regret this didn't go into the original spec - sorry Steve! One for v1.1. In the meantime, defaults can go into GUI specs (which to my intuition is a reasonably natural home for them anyway). 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 much - it's just two numbers rather than one in a XML network description or suchlike. There are plenty of IDs out there still if folk need more. I'd vote for use of a new plugin ID when an interface changes substantially - otherwise old saved networks will break. CHANGING CONTROL PARAMETERS DURING PROCESSING Hmm, this does sound like my style of specification English (and the "[at]" isn't appropriate IMHO!). I don't think it's unambiguous, although perhaps a little convoluted - the plugin is guaranteed that it can take sin(*ctrl) at the start of run() and cos(*ctrl) further on and get consistent results. It's important for a number of the reasons that the user and plugin know that the control value will stay fixed for the duration of the run() call. Some that spring to mind: (A) What happens when LADSPA runs on future hardware with small word sizes and larger floats? (B) Even if the float access is atomic, what happens when the host changes two interrelated control ports separately so inconsistent values are read by the plugin? (C) What happens if the C/C++ optimiser thinks it's more efficient to read twice from the control port? And it's pretty easy for the host to deal with the problem on its side. 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 all plugins would work with almost all hosts with minimal effort. This has worked - it's easy to add LADSPA support to hosts and the API is flexible enough for most of the common DSP algorithms out there (and we were still missing quite a few when I last looked, but then I haven't kept up with Steve's excellent efforts!). Because of this and because new programmers will carry on writing new hosts, I think we need to keep LAD*S*PA simple! That's just the host side of things - IMHO the API is already of borderline complexity for entry-level DSP plugin programmers. However, Ardour needs a richer plugin API. MN has one. VST has one. Quasimodo has one. aRts has one. GLAME has one. PD has one. Csound has one etc etc. So how should the Ardour team deal with the issue? Writing yet another incompatible API is obviously a bad idea. So I agree we need a richer API, however I don't think this should be done through extensions to LADSPA directly for reasons above. Instead, I'd like to see Ardour keep compatibility with LADSPA but for us to develop a new, richer API for the hard-core techies. It's probably be a good idea to base it on LADSPA to make it easier for programmers (of both plugin and host) to graduate from one API to the other. If it's done this way it could be called LADPA. I'm not 100% sure this is the way to go - different designs (such as LADMEA, see http://www.ladspa.org/ladmea/) may be appropriate once the horrors of memory allocation, unknown data types, network transparency etc are faced. I'll stop ranting now... --Richard
