[linux-audio-dev] LADSPA 2

Dave Robillard drobilla at connect.carleton.ca
Sun Apr 23 22:40:32 UTC 2006


On Sun, 2006-04-23 at 16:26 -0400, Dave Robillard wrote:
> On Sun, 2006-04-23 at 19:39 +0100, Steve Harris wrote:
> > On Sun, Apr 23, 2006 at 03:45:05PM -0400, Dave Robillard wrote:
> > > On Sun, 2006-04-23 at 19:23 +0100, Steve Harris wrote:
> > > > On Sun, Apr 23, 2006 at 11:25:59AM -0400, Dave Robillard wrote:
> > > > > But anyway, why can't it go in the code?  I want to keep the C part
> > > > > minimal as well, but this is a unique identifier, the sole thing that
> > > > > actually does belong in the code.  I need this to create an app/device
> > > > > like the above.  What's the better reason it's a bad idea?  Plugins have
> > > > > a unique string ID, and I need ports to as well.
> > > > 
> > > > Theres no advantage to it being in the code, it means allocating an array
> > > > of strings, which means repeating the same code in every plugin. Also, you
> > > > can't get the strings unless you load and link the plugin, which is one of
> > > > the things were trying to get away from.
> > > 
> > > The advantage is the mentioned use case which your suggestion destroys.
> > > The array can be static anyway, there's not really any "code" added.
> > 
> > I don't see how it affects the usecase. You /always/ need to read at least
> > some of the data somehwere to use the plugin.
> 
> Well, the plugin should be at least runnable without the metadata.  Sure
> you'll know almost nothing about it, but you should be able to run it
> (eg in fixed code where you know the parameters and whatnot you're using
> are fine).  (No user interacting app could feasibly do so though)
> 
> The "somewhere" part is my point.  This 'device' can not read metadata
> files, yet it needs to know the port IDs.  Therefore the port IDs need
> to be in the code.
> 
> > > Are you proposing to put the port index numbers in the metadata as well?
> > > Otherwise you couldn't get at them without loading and linking the
> > > plugin.
> > 
> > Of course, it's ladspa:index if the numbers aren't there then theres
> > nothing to link the port data to the float *.
> >  
> > > So the plugin URI should exclusively go in the metadata file as well?
> > > Why is that in the code?
> > 
> > It has to be in the struct, otherwise you don't know what functions to
> > call to get a particular plugin.
> 
> In other words it's there because it's a unique identifier for the
> plugin, used to reference it.  I say port IDs need to be there for the
> same reason.  Ports should be first class citizens with a proper
> identifier and all, IMO.
> 
> Anyway, putting IDs in the metadata implies that, well, they're
> metadata, and can be fiddled with without breaking things.  This is not
> true.  They are unique identifiers (along with their plugin's URIs they
> define a URI) and as such are set in stone and must not change.  They're
> just not metadata.
> 
> But I want to emphasize the 'device' (or trivial host app, etc) over
> arguments about word definitions etc.  I really don't want to have to
> fork LADSPA into an ABI incompatible derivative over something silly
> like this.

For the sake of the record, it's been duked out on IRC and Steve
wins :).  (Specifically, ports will be required to have a unique string
ID, but it will live in the data file, not the code).

The RDF file is required to run the plugin anyway, since port type and
direction etc. is contained there, making my argument about keeping the
data file parsing off the 'server side' invalid.

The data file is not a "metadata" file, it's required to execute the
plugin at all (and I fully agree with this now, even if it does throw a
bit of a monkey wrench in some embedded development plans of mine; it's
for the greater good....)
 
-DR-




More information about the Linux-audio-dev mailing list