Re: [linux-audio-dev] LADSPA 2

From: Dave Robillard <drobilla@email-addr-hidden>
Date: Tue May 02 2006 - 22:49:59 EEST

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:
>
>
> > 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,
> ....
> };

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.

>
> 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-
Received on Wed May 3 04:15:06 2006

This archive was generated by hypermail 2.1.8 : Wed May 03 2006 - 04:15:06 EEST