Subject: Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff)
From: Tim Goetze (tim_AT_quitte.de)
Date: Mon Mar 08 2004 - 16:48:22 EET
[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.
in the end, it's just a number, so i won't insist if more votes
against it will be heard.
[...]
>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.
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.
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.
>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.
-
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.
vriendelijk,
tim
This archive was generated by hypermail 2b28 : Mon Mar 08 2004 - 16:53:17 EET