26 Apr
2006
26 Apr
'06
12:05 a.m.
On Wed, Apr 26, 2006 at 03:11:10AM +0200, Leonard paniq Ritter wrote:
On Tue, 2006-04-25 at 19:59 -0400, Dave Robillard
wrote:
You are not alone on this one. I think it's great to have as much data
as possible in a place that need not be dlopened to access. However, if
I have to learn to use some whizz-bang library to read yet another
markup language, spend an hour at w3c to learn about all these
web-inspired formats, and grok some ladspa-specific schema to manipulate
a plugin, I think this Simple Plugin API has missed the mark.
Now, obviously the current example is incomplete, but whenever this
stuff is done, I shouldn't have to write more than 5 lines of C to shove
some bits through a plugin, and it shouldn't take me more than 5 minutes
from the time I google "ladspa documentation" to learn to do it.
If browsing or using ladspa plugins would require more than 5 lines of C
or learning some new technology or library that does far more than I
care about, I suggest the ladspa sdk include a well documented, simple
convenience library to do the things that any ladspa host would want to
do. This includes things like finding available plugins, and querying
them for version, description, documentation references, and loading.
If everything I need to know to use ladspa won't reasonably fit in a
header, it isn't simple.
If you think the header should be all the
documentation required, then
you completely Don't Get It on a fundamental level. Read the example
plugin - all of it.
i was able to implement a working ladspa host implementation only from
the header, and that was a good experience. i would like it if it could
stay that way. a tiny reference to an additional document that should be
read in the header would also be cool. not mentioning required
literature is unfriendly ;)