Hi Richard, hi others,
at the moment I am porting over about 60 plugins from SoundFX (www.sonicpulse.de
- an AMIGA shareware I am still developing and which you can use with UAE!) to
ladspa. I have sucessfully got the ladspa-sdk working on the Amiga too (added a
small wrapper lib to fix system level shared object differences)
From that work I've got some comments, suggestions and proposals for ladspa 1.1/2.0
1.) in _init() plugins should use calloc(), when extending the LADSPA_Descriptor
we would only need to make sure that we add to the end and that NULL/0 is a
sensible default. Then plugins could be ported by simple recompiling.
2.) I vote for inclusion of an API version as well. Let's do it as soon as we
don't have 1000 plugins. As already expressed, probably all authors are reading
this, it can be quickly added.
So what about having :
const LADSPA_Descriptor *ladspa2_descriptor(unsigned long index,unsigned long
host_version) {
if(LADSPA_H_VERSION>host_version) return(NULL);
}
now have the version in ladspa.h as e.g.
#define LADSPA_H_VERSION 2
3.) For the defaults, I don't like the new hints that much either, but they
don't hurt on the other hand. At the moment I play around with the RDF approach
and I will very probably support it.
4.) One feature I miss in the descriptor is grouping control ports
/* number of groups, 0 mean no grouping at all */
int Descriptor->PortGroupCount;
/* label of each group */
char Descriptor->PortGroupNames[Descriptor->PortGroupCount];
/* to which group belongs the port */
int Descriptor->PortGoups[Descriptor->PortCount];
I know that people now might even want to have hierarchical groups and more ...
I see this as very useful for plugins with many ports (like mine ;-) )
A decend GUI front end could even allow to fold/unfold groups.
5.) Adding a general description meta field. This can probably go to the rdf as
well. The gui could just show that text optionally along with the controls.
This would allow the plugin-developer to describe the controls to the user as
well (and not just to the host).
6.) Control-Domains. For SoundFX I have written a small library to convert
units. Therefore I have isolated 7 domains (like amplitude, frequency and time)
in the field of audio-applications. Supplying this along with the control port,
would eventually give the host a more precise clue than integer/logarithmic hints.
Apart from that I still see a problem for integer controls port. There is
currently no way to supply labels for the single values.
So, if we could agree to make a version 2 (which will break binary
compatibillity), then we should add a solution to this.
Easies and hackiest would be to extend the portname. Divide the portname with
'\0' into the port-label and the value labels. Old plugins would not read beyond
the first '\0'.
On the other hand, this is maybe something for RDF as well. Sorry for thinking
aloud ;-)
Any comments appreciated, but take your time, I'll be away for the next two weeks...
Stefan
--
\|/ Stefan Kost
<@ @> private business
+-oOO-(_)-OOo------------------------------------------------------ - - - - -
| __ Address Zwenkauer Str. 24 HTWK Leipzig, Fb IMN, Postfach 300066
| /// 04277 Leipzig 04277 Leipzig
| __ /// Germany Germany
| \\\/// Phone +49341 3910483 +49341 30766101
| \__/ EMail [EMAIL PROTECTED] [EMAIL PROTECTED]
| WWW www.sonicpulse.de www.imn.htwk-leipzig.de/~kost/about.html
===-=-=--=---=---------------------------------- - - - - -
