8 Mar
2004
8 Mar
'04
1:02 p.m.
[Steve Harris]
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.
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)"?
i'm trying to follow your previous argument of 'logically connected'.
for plugins with many ports, this is very convenient.
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
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 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. 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.