2009/6/18 Fons Adriaensen <fons(a)kokkinizita.net>et>:
On Thu, Jun 18, 2009 at 07:55:21PM +0200, Stefano
D'Angelo wrote:
Host will
need to use the value (UpperBound + 1) no matter
where these strings get stored. A host looping over the port
data should just initialise a pointer:
const char **enum_labels = descriptor->PortNames + descriptor->PortCount;
for (i = 0; i < descriptor->PortCount; i++)
{
// ...
if (enum_hint_is_set)
{
int nlabels = upperbound + 1;
// Copy 'nlabels' and 'enum_labels' to where you want
// them, normally something representing the widget.
// Copy the strings to the widget if necessary.
enum_labels += nlabels;
}
// ...
}
And that's all. The loop and everything in it, the 'if',
the 'nlabels' and the commented parts will be needed anyway,
the only 'typical' code are the two lines initialising and
incrementing 'enum_labels'. I don't think it could be any
simpler.
Ahem... this is not so simple on both plugin and host side IMO, and
would make the API less usable for people who don't make a living out
of C programming.... another possible (and better IMO) solution is
already available: LRDF. We already have enumerated port values for
LADSPA there.
Are you serious ? Almost all of this code you need ANYWAY no
matter where and how the labels are stored. The only two
lines typical for the proposed way are the initialisation
and increment of the enum_labels pointer.
You would have to add the names in order of (port index, value),
starting from PortNames + PortCount... is this really so intuitive to
someone who occasionaly does C?
Storing the labels in any other way would require at
least
as much code typical for doing it in that way, and it wouldn't
be simpler.
Yes, but we already have that (I don't know if any host supports that
already, though). The hint, instead, sounds right to me.
I don't want to be rude, but anyone having a
problem
understanding this should not even *think* of writing
a host. He/she will have many much more difficult things
to write.
We don't care about host authors with LADSPA, but about plugin
authors, right? Well..
The plugin itself does not need the labels.
Need != want.
All this I've already said five years ago, with
the
same reactions from people who apparently don't take
the time to think before posting. I'm not going to
repeat that entire thread.
I don't want to repeat nothing, I really don't care, and any solution
(even none) is fine with me. I was just making a suggestion and you,
as usual, are bashing people claiming they don't use their brain when
you disagree... you're becoming too Italian man (and here's an Italian
writing this mail).
Stefano