2 May
2006
2 May
'06
5:16 p.m.
On Tue, 2006-05-02 at 13:50 +0200, Alfons Adriaensen wrote:
On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave
Robillard wrote:
That would be a valid point if all the data that people wanted to
associate with plugins was strictly defined right now (which is
impossible). That is the whole problem with LADSPA1 that we need to fix
here, hence the external data file.
You are completely missing the entire point of
LADSPA2. All the
unecessary data has been removed from the header file (ie the plugin
code).
Look at the example plugin's code, it will be painfully obvious what the
advantage is.
A lot of plugins create what is essentially a block of constants by
dynamically allocating and initialising every bit of it. ISTR there was
(is) even an 'offical' plugin example source doing it that way.
Compared to that the new code is indeed simpler. But it's a braindead
way of doing it really, and that makes the comparison totally invalid.
I really don't see what is 'complex' or 'difficult' about e.g.
static const LADSPA_PortDescriptor pdesc0 [Ladspa_G2reverb::NPORT] =
{
LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_INPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_INPUT | LADSPA_PORT_CONTROL,
....
};
Further, you can't really remove all of this data. Most of it
will be required by the plugin code itself, and you can't expect
it to go and read it from the RDF.
Since the plugin author writes both and they are strongly associated
with (and depend on) each other, the plugin can 'assume' eg. the type of
it's ports. Plugin code definitely won't be reading the RDF file.
-DR-