Subject: RE: [linux-audio-dev] LADSPA Update, New Project (CMT) & HelpRequested
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Mon May 08 2000 - 04:53:45 EEST
The underlying logic was that the ladspa_descriptor() function returns a
handle to a static/global plugin descriptor. Unfortunately this isn't
explicit in the header. For a more purist approach, _init() and _fini() are
the places to handle malloc() and free() for the structures required.
Although I don't seem able to build with _init() - clashes with crti
library apparently. I'm probably doing something stupid (any ideas?) - once
I've sorted this out I'll update the example plugins & CMT to make this
clearer.
The ImplementationData hook is there for the plugin writer to allocate (or
not) and use in any way he/she sees fit. The host must pretend it isn't
there.
-- Richard
-----Original Message-----
From: David Benson [SMTP:daveb_AT_idealab.com]
Sent: Friday, May 05, 2000 3:19 PM
To: Juhana Sadeharju
Cc: linux-audio-dev_AT_ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] LADSPA Update, New Project (CMT) &
HelpRequested
> Another point: who sets and frees the
> void * ImplementationData;
> structure of Descriptor? Both delay.c and filter.c don't do it, and
> host cannot even check if something is there or not.
>
> Also, since plug-in doesn't free the descriptor structure (and thus
> ImplementationData) and because host cannot even guess the content of
> the ImplementationData, the ImplementationData is left unfreed in any
> case even host knows the Descriptor structure and can free it.
I agree: this field seems useless until we have a
descriptor::destroy_plugin(LADSPA_Descriptor*);
and indeed, that would be good, albeit late.
[...]
This archive was generated by hypermail 2b28 : Mon May 08 2000 - 05:37:19 EEST