[linux-audio-dev] +momentary, consolidated (ladspa.h.diff)

Steve Harris S.W.Harris at ecs.soton.ac.uk
Mon Mar 8 15:29:31 UTC 2004


On Mon, Mar 08, 2004 at 03:48:22 +0100, Tim Goetze wrote:
> [Steve Harris]
> >On Mon, Mar 08, 2004 at 01:39:36AM +0100, Tim Goetze wrote:
> >> * a patch moving ladspa.h 1.1 to 2.0
> >
> >Why 2.0? I thought we were aiming for binary compatibility. 1.2 seems more
> >technically correct and less offputting to developers.
> 
> the patch introduces API versioning in a clean, backward- as well as
> forward-compatible fashion. imo, this is reason enough to bump the
> major. add to this that it deprecates a 1.1 core feature (default
> hints) if not convinced.

2.0 implies a substantial rewrite and no backward compatibility.
 
> in the end, it's just a number, so i won't insist if more votes
> against it will be heard.

Fair enough.

> [...]
> >I dont see how any host that is not using metadata can make any use of a
> >units field, the .h file allready suggests that plugins should provide
> >lexical forms for the units in the port name: 'This member [PortNames]
> >indicates an array of null-terminated strings describing ports (e.g.
> >"Frequency (Hz)").' and I dont think seperating it helps unless youre
> >working at a non-lexical level, which means external metadata.
> 
> i don't dig your reasoning: you say the unit is 'metadata' yet you
> don't object to it appearing in the port name, where it is redundant
> with *any* other way, RDF or PortInfo, of specifying it.

There are allready a /lot/ of plugins with unit names in brackects at the
end of port names. You can't parse them out, but why would you? What are
you going to do with the unit name other than display it, unless you have
metadata?
 
> it also clutters one field (the name) by using it for two orthogonal
> purposes, which must be a nightmare for somebody using as strict a
> distinction of data modes as you do.

Its not a big issue. The port name is only for display purposes. If you
label the units seperatly all you would see is
sprintf(label, "%s (%s)", port_label, port_units) anyway.

If I wanted to use metadata to describe units of parameters (I dont think
I do right now) I would want to do a lot more than just name them.
 
> if we want a clean API, units don't belong in the port name. right
> now, it takes a string-splitting hack to extract them for a host,
> which will even fail miserably when somebody chooses to call a port
> "gain (linear)", "drive (preamp)", "frequency (LFO)" etc etc.

I dont see why the host would need/want to do that. If they want metadata
for units then describe them in metadata terms, dont hack it into the
plugins desriptor lexically. The metadata to plugin mapping works because
the id's are guaranteed inverse-functional. Unit labels are not.  
The host cant do anything useful given just a unit label.

> >For symmetry with the existing implementation (and ease of future
> >extensions) the PortInfo structure should probably be seperate member
> >fields of the plugin struct. Ranges are a struct, but they are logically
> >connected and not extensible as they are not explicitly sized.
> 
> good that you mention it. we could make future extensions a lot less
> painful if we padded the PortInfo structure with reserved space. it's
> not particularly nice, but very sensible.

Wouldn't it be easier to just move them out of the sub-struct? Then you
dont need any padding. It also fits better with the rest of the API.

> i would like to conclude this post with another 'political' statement:
> 
> relying on hacks like the default value hints, "name (unit)" or a
> separate file and format for vital information is what will scare off
> developers. it may all seem manageable to you now, but it will not be
> to anyone. we should grab the chance to keep things tidy while we
> still have it.

Agreed. I think we differ on what are the hacks, and what is vital though.
Also, I think the most offputting thing for devlopers is complexity. Its
often what seperates successful APIs from failed ones, especially in the
plugin world.

- Steve



More information about the Linux-audio-dev mailing list