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

[Tim Goetze]

[Steve Harris]
>> 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.

then what about "Frequency: 440 Hz"?

it's, forgive me the perception-oriented argumentation, far more
natural and easy to read than "Frequency (Hz): 440".

if you look closely, it also saves two characters of output, which can
amount to a significant savings in screen real estate with many
plugins and ports being used. for an embedded device with a very small
display, this can even become vital.

more space can be saved by hosts choosing to ignore the unit
altogether.


>> 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.

we have already agreed to disagree on the definition of vital data in
this context, so assuming your definition is the common basis of
discussion seems unrealistic.

and to repeat: if you don't want units to appear in the plugin
sources, why are you satisified with "Frequency (Hz)"?


>> 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'm trying to follow your previous argument of 'logically connected'.
for plugins with many ports, this is very convenient.


>> 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.

yup, it seems pretty hard to converge on such simple things. there are
two kinds of complexity in APIs i think: explicit and implicit.

explicit complexity is, roughly, a function of the number of lines in
the API header files.

implicit complexity, once again roughly, is a function of the number
of lines in an implementation of the API, and of the readability of
this implementation.

i prefer explicit over implicit in this context; it means less nasty
surprises.

vriendelijk,

tim