18 Jun
2009
18 Jun
'09
12:28 p.m.
hi everybody!
as discussed in another thread, i would like to propose a new LADSPA
release 1.2, which should include the following changes:
1. addition of a port range hint flag LADSPA_HINT_PERIODIC to denote
periodic behaviour of a control port to be added to the
LADSPA_PortRangeHintDescriptor bit field.
if present, both LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE must be specified as well. moreover,
both LowerBound and UpperBound must be present in the corresponding
LADSPA_PortRangeHint struct.
the presence of LADSPA_HINT_PERIODIC implies that LowerBound is
equivalent to UpperBound.
hosts should consider displaying a widget that reflects the periodic
nature of the corresponding control value, such as a rotary control.
hosts that interpolate between control values defined by the user
(such as automation points in a DAW) should take into account that
the shortest path between two given values might cross the
boundary defined by LowerBound resp. UpperBound and behave
accordingly.
usage example: soundfield rotators, circular panners
2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform
hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
should be annotated with a set of labels rather than numbers.
LADSPA_HINT_ENUMERATED mandates the following:
LADSPA_HINT_INTEGER is set.
LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be set.
in LADSPA_PortRangeHint, LowerBound must be 0, UpperBound must be >0.
the number of labels provided must be equal to (UpperBound - 1).
some of these mandatory settings are redundant and could be handled
as being implicit.
however, for the sake of backwards compatibility and to to allow
older hosts to display a meaningful UI even if they don't implement
the new flag yet, all these items MUST be set.
as to the location of the actual enum of labels: fons adriaensen
suggests adding them to the end of the PortNames array.
this implies that for multiple enum-labelled controls, the labels
would have to be concatenated and the host would have to tell them
apart by keeping track of the corresponding UpperBound offsets, which
might become a little messy. your comments are welcome.
best,
jörn
18 Jun
18 Jun
1:48 p.m.
On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn Nettingsmeier wrote:
2. addition of a port range hint flag
LADSPA_HINT_ENUMERATED to inform
hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
should be annotated with a set of labels rather than numbers.
LADSPA_HINT_ENUMERATED mandates the following:
LADSPA_HINT_INTEGER is set.
LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be set.
in LADSPA_PortRangeHint, LowerBound must be 0, UpperBound must be >0.
the number of labels provided must be equal to (UpperBound - 1).
??? This should be (UpperBound + 1) AFAICS
Example: legal values = 0,1,2,3,4
Upperbound = 4, number of labels = 5
some of these mandatory settings are redundant and
could be handled
as being implicit.
however, for the sake of backwards compatibility and to to allow
older hosts to display a meaningful UI even if they don't implement
the new flag yet, all these items MUST be set.
as to the location of the actual enum of labels: fons adriaensen
suggests adding them to the end of the PortNames array.
this implies that for multiple enum-labelled controls, the labels
would have to be concatenated and the host would have to tell them
apart by keeping track of the corresponding UpperBound offsets, which
might become a little messy. your comments are welcome.
This makes is backwards compatible, as no new field is required
in the descriptor struct.
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.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
1:53 p.m.
Fons Adriaensen wrote:
On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn
Nettingsmeier wrote:
obviously, sorry for the confusion.
2. addition of a port range hint flag
LADSPA_HINT_ENUMERATED to inform
hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
should be annotated with a set of labels rather than numbers.
LADSPA_HINT_ENUMERATED mandates the following:
LADSPA_HINT_INTEGER is set.
LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be set.
in LADSPA_PortRangeHint, LowerBound must be 0, UpperBound must be >0.
the number of labels provided must be equal to (UpperBound - 1).
??? This should be (UpperBound + 1) AFAICS 
1:55 p.m.
2009/6/18 Fons Adriaensen <fons(a)kokkinizita.net>et>:
On Thu, Jun 18, 2009 at 06:28:32PM +0200, Jörn
Nettingsmeier wrote:
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.
Stefano
2. addition of a port range hint flag
LADSPA_HINT_ENUMERATED to inform
hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
should be annotated with a set of labels rather than numbers.
LADSPA_HINT_ENUMERATED mandates the following:
LADSPA_HINT_INTEGER is set.
LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be set.
in LADSPA_PortRangeHint, LowerBound must be 0, UpperBound must be >0.
the number of labels provided must be equal to (UpperBound - 1).
??? This should be (UpperBound + 1) AFAICS
Example: legal values = 0,1,2,3,4
Upperbound = 4, number of labels = 5
some of these mandatory settings are redundant
and could be handled
as being implicit.
however, for the sake of backwards compatibility and to to allow
older hosts to display a meaningful UI even if they don't implement
the new flag yet, all these items MUST be set.
as to the location of the actual enum of labels: fons adriaensen
suggests adding them to the end of the PortNames array.
this implies that for multiple enum-labelled controls, the labels
would have to be concatenated and the host would have to tell them
apart by keeping track of the corresponding UpperBound offsets, which
might become a little messy. your comments are welcome.
This makes is backwards compatible, as no new field is required
in the descriptor struct.
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. 
2:31 p.m.
This has been debated already. Several times. For instance, please
follow this (long) thread:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
While I think that each side of the argument has its merits, in the
end to me it all boils down to: "is lrdf simple and lightweight enough
so it is acceptable to consider it from a practical point of view a
de-facto mandatory extension of ladspa.h for all but the simplest of
hosts and plugins?"
My personal answer is "mmm... okay, I guess" but I don't think we will
ever reach a global consensus on this.
L
2:46 p.m.
2009/6/18 Luis Garrido <luisgarrido(a)users.sourceforge.net>
This has been debated already. Several times. For
instance, please
follow this (long) thread:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
While I think that each side of the argument has its merits, in the
end to me it all boils down to: "is lrdf simple and lightweight enough
so it is acceptable to consider it from a practical point of view a
de-facto mandatory extension of ladspa.h for all but the simplest of
hosts and plugins?"
My personal answer is "mmm... okay, I guess" but I don't think we will
ever reach a global consensus on this.
We have basically five alternatives, I guess:
1. Forget about this;
2. Implement this breaking the ABI (API too?);
3. Do as Fons suggested (which to me sounds like make that tiny part of the
API a bit counter-intuitive);
4. Use LRDF;
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
I'd choose 4 or 5, but in the end I don't really care, whatever is fine with
me.
Stefano
2:48 p.m.
2009/6/18 Stefano D'Angelo <zanga.mail(a)gmail.com>om>:
2009/6/18 Luis Garrido
<luisgarrido(a)users.sourceforge.net>
Oops, I was meaning struct ladspa_port_value_enum **
ladspa_get_port_value_enums(unsigned long descriptor_index, unsigned
long port_index);
Returned value is a NULL-terminated array of pointers... well, whatever.
Stefano
This has been debated already. Several times. For instance, please
follow this (long) thread:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
While I think that each side of the argument has its merits, in the
end to me it all boils down to: "is lrdf simple and lightweight enough
so it is acceptable to consider it from a practical point of view a
de-facto mandatory extension of ladspa.h for all but the simplest of
hosts and plugins?"
My personal answer is "mmm... okay, I guess" but I don't think we will
ever reach a global consensus on this.
We have basically five alternatives, I guess:
1. Forget about this;
2. Implement this breaking the ABI (API too?);
3. Do as Fons suggested (which to me sounds like make that tiny part of the
API a bit counter-intuitive);
4. Use LRDF;
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
I'd choose 4 or 5, but in the end I don't really care, whatever is fine with
me.
Stefano 
23 Jun
23 Jun
3:52 a.m.
Stefano D'Angelo schrieb:
2009/6/18 Stefano D'Angelo
<zanga.mail(a)gmail.com>om>:
I like the idea of the function. A nice feature of buzzmachine plugins
is that plugins can have a describe_value() function. It returns a port
value as a string. This is very flexible as plugins can include the unit
values or other characters in the string (e.g. "90°", "4½" or
"±0").
a)
For ladspa we could add a
const char *describe_port_value(LADSPA_Handle Instance, unsigned long Port);
to the end of _LADSPA_Descriptor.
For that we would need to add a ladspa_get_api_version() and only access
this for plugins that return >=1.2.
b)
Have a ladspa_descriptor_ext() function that exists only >1.2 and will
include a version in the descriptor.
My point is if we consider adding more public function to the api, it
would be good to version it.
Adding the enum to the end of portname will work, but I see not so much
benefit here to change the semantics of portnames. once a host has some
lrdf support its no so difficult to get more metadata out from it.
Stefan
2009/6/18 Luis Garrido
<luisgarrido(a)users.sourceforge.net>
Oops, I was meaning struct ladspa_port_value_enum **
ladspa_get_port_value_enums(unsigned long descriptor_index, unsigned
long port_index);
Returned value is a NULL-terminated array of pointers... well, whatever.
Stefano
This has been debated already. Several times. For
instance, please
follow this (long) thread:
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2004-March/006948.html
While I think that each side of the argument has its merits, in the
end to me it all boils down to: "is lrdf simple and lightweight enough
so it is acceptable to consider it from a practical point of view a
de-facto mandatory extension of ladspa.h for all but the simplest of
hosts and plugins?"
My personal answer is "mmm... okay, I guess" but I don't think we will
ever reach a global consensus on this.
We have basically five alternatives, I guess:
1. Forget about this;
2. Implement this breaking the ABI (API too?);
3. Do as Fons suggested (which to me sounds like make that tiny part of the
API a bit counter-intuitive);
4. Use LRDF;
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
I'd choose 4 or 5, but in the end I don't really care, whatever is fine with
me.
Stefano
4:34 a.m.
Stefan Kost wrote:
I like the idea of the function. A nice feature of
buzzmachine plugins
is that plugins can have a describe_value() function. It returns a port
value as a string. This is very flexible as plugins can include the unit
values or other characters in the string (e.g. "90°", "4½" or
"±0").
That's basically why I proposed it :) It worked well in Buzz, that's for
sure :)
Krzysztof
18 Jun
18 Jun
2:57 p.m.
On Thu, Jun 18, 2009 at 08:46:28PM +0200, Stefano D'Angelo wrote:
3. Do as Fons suggested (which to me sounds like make
that tiny part of the
API a bit counter-intuitive);
It's just a conceptual change. The port_names array
becomes a general-purpose string table, the first
NPORT values are the port names, followed by any
enumerated labels if present, in the order you
would probably need them.
4. Use LRDF;
This is already available in the LRDF 'version'
of LADSPA. The whole point is to make it available
in the non-LRDF way of doing things.
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
Would not be backwards compatible as far as I can see.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
2:58 p.m.
2009/6/18 Fons Adriaensen <fons(a)kokkinizita.net>et>:
Uh? Why not? Exporting a new symbol breaks API/ABI???
Stefano
5. Add
something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
Would not be backwards compatible as far as I can see. 
4:38 p.m.
On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen
<fons(a)kokkinizita.net>et>:
Uh? Why not? Exporting a new symbol breaks API/ABI???
You mean adding a function outside the LADSPA_Descriptor, don't you?
i.e. another function like ladspa_descriptor(). (There seems to be some
confusion!)
I think your idea is cleaner than Fons', and has the advantage of
allowing non-integer values for the settings.
Damon
5. Add
something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
Would not be backwards compatible as far as I can see.
4:52 p.m.
2009/6/18 Damon Chaplin <damon(a)karuna.eclipse.co.uk>uk>:
On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
Yes, sorry if I didn't make it clear enough.
2009/6/18 Fons Adriaensen
<fons(a)kokkinizita.net>et>:
Uh? Why not? Exporting a new symbol breaks API/ABI???
You mean adding a function outside the LADSPA_Descriptor, don't you?
i.e. another function like ladspa_descriptor(). (There seems to be some
confusion!) 5. Add
something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
Would not be backwards compatible as far as I can see. I think your idea is cleaner than Fons', and has
the advantage of
allowing non-integer values for the settings.
Well, the main advantage is that we can pollute the "ladspa_
namespace" as we like without API/ABI problems (future proof yeah :-P)
Stefano
2:34 p.m.
On Thu, Jun 18, 2009 at 07:55:21PM +0200, Stefano D'Angelo wrote:
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.
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.
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.
The plugin itself does not need the labels.
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.
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
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.
2:54 p.m.
2009/6/18 Fons Adriaensen <fons(a)kokkinizita.net>et>:
On Thu, Jun 18, 2009 at 07:55:21PM +0200, Stefano
D'Angelo wrote:
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?
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. 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
3:31 p.m.
On Thu, Jun 18, 2009 at 08:54:39PM +0200, Stefano D'Angelo wrote:
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?
Should someone who 'occasionaly does C' write a
plugin host ? It's not going to end well, and
that won't be because of what I propose.
And in the plugin itself it's trivially easy.
An example:
static const char * const strings [] =
{
// Port names
"In-L",
"In-R",
"Out-L",
"Out-R",
// Labels for the mono / stereo switch
"Mono",
"Stereo",
// Labels for the reverb type selection
"Concert hall",
"Small church",
"Vocal plate",
"Bathroom"
};
etc.
Of course, if someone would generate this array dynamically
(some people do this, just copying string constants from A
to B which is quite silly) that means they are complicating
things for themselves.
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...
Not because I disagree, and nothing personal.
But if you read the code I posted, and the comments
provided with it, and think about this for a second,
you can't honestly say it's complicated. Anyone who
can write C can grok this code and the intention
behind it in no time.
you're becoming too Italian man (and here's an
Italian
writing this mail).
:-) Is it as hot where you are ?
Ciao !
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
4:50 p.m.
2009/6/18 Fons Adriaensen <fons(a)kokkinizita.net>et>:
He has to read this code, otherwise explaining it could create
confusion, and not everybody wants to read someone else's code.
I have a fan pushing air on my back all day :-P
Maybe the solution I posted here is a little bit cleaner and
future-proof... maybe!
Stefano
On Thu, Jun 18, 2009 at 08:54:39PM +0200, Stefano
D'Angelo wrote:
Nope. I was only talking about the author of the plugin, not the host author.
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?
Should someone who 'occasionaly does C' write a
plugin host ? It's not going to end well, and
that won't be because of what I propose. And in the plugin itself it's trivially easy.
... once you show him how to do (which could be added to the header
comments), but it could maybe easy for the unexperienced plugin
developer to make confusion?
An example:
static const char * const strings [] =
{
// Port names
"In-L",
"In-R",
"Out-L",
"Out-R",
// Labels for the mono / stereo switch
"Mono",
"Stereo",
// Labels for the reverb type selection
"Concert hall",
"Small church",
"Vocal plate",
"Bathroom"
};
Now, suppose you wanted to add other kind of stuff in some future to
ports: if they are strings, you could do this thing once again (maybe,
maybe not), if they are not strings (e.g. units of measure as an
enum), how to do that with this same approach? Add as strings and ask
the host to perform the conversion? The more stuff in there, the more
likely it will get difficult to use/understand.
Plus, you can't change the name of the parameter (PortNames) in the
descriptor, without breaking API, which is weird.
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...
Not because I disagree, and nothing personal.
But if you read the code I posted, and the comments
provided with it, and think about this for a second,
you can't honestly say it's complicated. Anyone who
can write C can grok this code and the intention
behind it in no time. you're
becoming too Italian man (and here's an Italian
writing this mail).
:-) Is it as hot where you are ?
5:33 p.m.
On Thu, Jun 18, 2009 at 10:50:45PM +0200, Stefano D'Angelo wrote:
I have a fan pushing air on my back all day :-P
I found it kind of funny the latest weeks to be surrounded
by 'locals' complaining about the temperature. They should
be used to it... :-) When I was in Senegal some years ago
*that* was hot. But the locals there found it quite normal
and used to make fun of those poor tourists...
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
Now, suppose you wanted to add other kind of stuff in
some future to
ports: if they are strings, you could do this thing once again (maybe,
maybe not), if they are not strings (e.g. units of measure as an
enum), how to do that with this same approach? Add as strings and ask
the host to perform the conversion? The more stuff in there, the more
likely it will get difficult to use/understand.
I don't claim this is the universal solution to all
problems of this sort. It solves this one, that and
that's all.
We had the same discussion 5 years ago, it ended
in nothing happening at all, and nothing was added
to ALSA since. I don't think much more is to follow,
as we now have other standards such LRDF for Alsa
and LV2. Still, not being able to have labels for
enumerated params remains a gaping hole - it's the
missing thing if you want to make a simple GUI based
on the info provided by the plugin (and nothing else).
I would like to see it filled, even if that is the
last thing that gets added. I do really not think
many people will use it, but those that don't can
ignore it.
Plus, you can't change the name of the parameter
(PortNames) in the
descriptor, without breaking API, which is weird.
You can. Fields are not referred to by name in compiled
code. Host and plugins can use different names, except
for symbols that are looked up by dlsym().
He has to read this code, otherwise explaining it
could create
confusion, and not everybody wants to read someone else's code.
Not really. Labels follow the part names, in the same
array. In the order you'd expect. That's all you need
to know. The code I posted serves only to demonstrate
that you don't need a genius to handle this. You're
free to write it in any other way you like.
Plus, 'not everybody want to read someone else's code'
may be true, but still everybody, at least in my world,
is responsable for the consequences of his/her own
choices including that one. I have learned probably
99% of what I know about C/C++ programming by reading
other people's code, and I would not advise anyone to
not do that.
you're becoming too Italian man (and here's an
Italian
writing this mail).
:-) Is it as hot where you are ?
6:13 p.m.
2009/6/18 Fons Adriaensen <fons(a)kokkinizita.net>et>:
As long as you don't try to recompile your 1.1 host against a 1.2
header, yes... but not all hosts come with a copy of ladspa.h in their
source tree (at least I don't in my project... maybe I should??). This
would break balls to gentoo/arch/etc. people (and I am an arch user)
:-)
I have a fan pushing air on my back all day :-P
I found it kind of funny the latest weeks to be surrounded
by 'locals' complaining about the temperature. They should
be used to it... :-) When I was in Senegal some years ago
*that* was hot. But the locals there found it quite normal
and used to make fun of those poor tourists...
Well, I am in Turin now, but I come from a little village in the South
which is way cooler and drier and A LOT less polluted than this city.
Anyway, I guess in Senegal it is always hot, while in Italy it is hot
in summer and relatively cold in winter, this might explain why people
complain, maybe (and maybe, Italian people just like to complain
sometimes ;-)
Stefano
Plus, you
can't change the name of the parameter (PortNames) in the
descriptor, without breaking API, which is weird.
You can. Fields are not referred to by name in compiled
code. Host and plugins can use different names, except
for symbols that are looked up by dlsym(). you're
becoming too Italian man (and here's an Italian
writing this mail).
:-) Is it as hot where you are ?
6:58 p.m.
On Fri, Jun 19, 2009 at 12:13:26AM +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen
<fons(a)kokkinizita.net>et>:
As long as you don't try to recompile your 1.1 host against a 1.2
header, yes... but not all hosts come with a copy of ladspa.h in their
source tree (at least I don't in my project... maybe I should??). This
would break balls to gentoo/arch/etc. people (and I am an arch user)
:-)
That's the classical problem when any dependency gets updated.
When I wrote my very first plugin (something like 7 years ago
IIRC) and it was reviewed by the LADSPA gods, they advised me
(to my surprise - even today) to include a copy of ladspa.h
with the sources.
Plus, you
can't change the name of the parameter (PortNames) in the
descriptor, without breaking API, which is weird.
You can. Fields are not referred to by name in compiled
code. Host and plugins can use different names, except
for symbols that are looked up by dlsym(). Well, I am in Turin now, but I come from a little
village in the South
which is way cooler and drier and A LOT less polluted than this city.
Anyway, I guess in Senegal it is always hot, while in Italy it is hot
in summer and relatively cold in winter,
Yes, winters here in Parma are worse than in Belgium.
Pollution here is probably less than in Turin. In fact
since mid may the whole region, and even the center of
Parma has this intense 'tiglio' perfume in the air.
(don't remember the English word for this...)
this might explain why people complain maybe (and
maybe,
Italian people just like to complain sometimes ;-)
:-) If I were Italian I'd complain about Il Cavaliere :-)
But this is driving us quite OT.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
7:44 p.m.
2009/6/19 Fons Adriaensen <fons(a)kokkinizita.net>
You lucky... I know a guy who studies at the university there and he comes
from my hometown, but never talked to him about Parma. He studies
"Ingegneria Informatica" there IIRC.
I don't want to spell out a single word on this ;-) However, yeah, it's
getting very OT.
Stefano
On Fri, Jun 19, 2009 at 12:13:26AM +0200, Stefano
D'Angelo wrote:
Maybe it's time to add it for me, then;-)
2009/6/18 Fons Adriaensen
<fons(a)kokkinizita.net>et>:
As long as you don't try to recompile your 1.1 host against a 1.2
header, yes... but not all hosts come with a copy of ladspa.h in their
source tree (at least I don't in my project... maybe I should??). This
would break balls to gentoo/arch/etc. people (and I am an arch user)
:-)
That's the classical problem when any dependency gets updated.
When I wrote my very first plugin (something like 7 years ago
IIRC) and it was reviewed by the LADSPA gods, they advised me
(to my surprise - even today) to include a copy of ladspa.h
with the sources.
Plus, you
can't change the name of the parameter (PortNames) in the
descriptor, without breaking API, which is weird.
You can. Fields are not referred to by name in compiled
code. Host and plugins can use different names, except
for symbols that are looked up by dlsym(). Well, I am in Turin now, but I come from a little
village in the South
which is way cooler and drier and A LOT less polluted than this city.
Anyway, I guess in Senegal it is always hot, while in Italy it is hot
in summer and relatively cold in winter,
Yes, winters here in Parma are worse than in Belgium.
Pollution here is probably less than in Turin. In fact
since mid may the whole region, and even the center of
Parma has this intense 'tiglio' perfume in the air.
(don't remember the English word for this...) this might
explain why people complain maybe (and maybe,
Italian people just like to complain sometimes ;-)
:-) If I were Italian I'd complain about Il Cavaliere :-)
But this is driving us quite OT. 
2:53 p.m.
[Fons Adriaensen]
This makes is backwards compatible, as no new field is required
in the descriptor struct.
AFAICS, binary compatibility is not compromised by an expanded
descriptor struct, as long as additional members are appended to the
struct.
(That is not to say it's hugely preferable introducing a new char **
PortValueLabels to appending these to the existing PortNames array -
just to point out that it is possible without breaking things.)
Cheers, Tim
4:22 p.m.
On Thu, Jun 18, 2009 at 08:53:27PM +0200, Tim Goetze wrote:
[Fons Adriaensen]
This is not strictly true. Indexing an array of such structs
will fail if the code doing it is generated by a compiler that
didn't use the exact size.
But that will indeed not to happen, as hosts are assumed to use
ladspa_descriptor() provided by the plugin.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
This makes is backwards compatible, as no new field is required
in the descriptor struct.
AFAICS, binary compatibility is not compromised by an expanded
descriptor struct, as long as additional members are appended to the
struct.
4:57 p.m.
2009/6/18 Fons Adriaensen <fons(a)kokkinizita.net>et>:
On Thu, Jun 18, 2009 at 08:53:27PM +0200, Tim Goetze
wrote:
Note: a weird host could copy make a copy of the descriptors (I see
nothing claiming this should not happen in the header file), thus ABI
would be broken... this could maybe happen in LADSPA hosts written in
non-C languages (why does Java come to my mind?).
Stefano
[Fons Adriaensen]
This is not strictly true. Indexing an array of such structs
will fail if the code doing it is generated by a compiler that
didn't use the exact size.
But that will indeed not to happen, as hosts are assumed to use
ladspa_descriptor() provided by the plugin.
This makes is backwards compatible, as no new field is required
in the descriptor struct.
AFAICS, binary compatibility is not compromised by an expanded
descriptor struct, as long as additional members are appended to the
struct.
5:17 p.m.
[Stefano D'Angelo]
Note: a weird host could copy make a copy of the descriptors (I see
nothing claiming this should not happen in the header file), thus ABI
would be broken... this could maybe happen in LADSPA hosts written in
non-C languages (why does Java come to my mind?).
No, it's not a problem. A host that does this is just treating the
plugin as a 1.1 version and ignoring the extra fields of the struct,
which is completely legal and causes no problems whatsoever.
Besides, the ladspa.h file states:
"""The plugin descriptor from which this instantiate function was
found must also be passed."""
when describing the instantiate() method of the plugin, the only one
that takes a descriptor pointer as an argument, effectively precluding
the plugin code stumbling across the use of a copied descriptor struct
as you describe it.
Cheers, Tim
5:23 p.m.
2009/6/18 Tim Goetze <tim(a)quitte.de>de>:
[Stefano D'Angelo]
As long as new stuff is added at the end of the struct (after all other fields).
Note: a weird host could copy make a copy of the descriptors (I see
nothing claiming this should not happen in the header file), thus ABI
would be broken... this could maybe happen in LADSPA hosts written in
non-C languages (why does Java come to my mind?).
No, it's not a problem. A host that does this is just treating the
plugin as a 1.1 version and ignoring the extra fields of the struct,
which is completely legal and causes no problems whatsoever. Besides, the ladspa.h file states:
"""The plugin descriptor from which this instantiate function was
found must also be passed."""
when describing the instantiate() method of the plugin, the only one
that takes a descriptor pointer as an argument, effectively precluding
the plugin code stumbling across the use of a copied descriptor struct
as you describe it.
Sorry, didn't see that. Well, I guess there's no problem on the plugin
side then... any other possible problems on the host side?
In case there are none, we could add an array or another callback.
Stefano
5:47 p.m.
On Thu, 2009-06-18 at 23:23 +0200, Stefano D'Angelo wrote:
Sorry, didn't see that. Well, I guess there's
no problem on the plugin
side then... any other possible problems on the host side?
In case there are none, we could add an array or another callback.
You'd need a way to let the host know if the plugin is version 1.1 or
1.2. Otherwise the host might try to use the new fields which might be
garbage.
I can't see a way of getting a LADSPA version number from a plugin at
present. Maybe a ladspa_version() function could be added (outside
LADSPA_Descriptor!), defaulting to 1.1.
But I'd probably just go for the ladspa_get_port_value_enums() function
and leave LADSPA_Descriptor untouched, just to be safe.
Damon
5:59 p.m.
2009/6/18 Damon Chaplin <damon(a)karuna.eclipse.co.uk>
On Thu, 2009-06-18 at 23:23 +0200, Stefano D'Angelo wrote:
You're right. Well, I vote for the extra function and leaving descriptor
untouched too.
Stefano
Sorry, didn't see that. Well, I guess
there's no problem on the plugin
side then... any other possible problems on the host side?
In case there are none, we could add an array or another callback.
You'd need a way to let the host know if the plugin is version 1.1 or
1.2. Otherwise the host might try to use the new fields which might be
garbage.
I can't see a way of getting a LADSPA version number from a plugin at
present. Maybe a ladspa_version() function could be added (outside
LADSPA_Descriptor!), defaulting to 1.1.
But I'd probably just go for the ladspa_get_port_value_enums() function
and leave LADSPA_Descriptor untouched, just to be safe
19 Jun
19 Jun
4:20 a.m.
Stefano D'Angelo wrote:
You're right. Well, I vote for the extra function
and leaving descriptor
untouched too.
What if that extra function was more of "get textual representation of a
particular float value" (see: Buzz MDK) instead of "get all strings"?
Added bonus: we could use it to provide textual representations of
non-enums.
Sorry for dropping it in at the last moment, I really got stuck in that
"enum" mindset...
Krzysztof
8:07 a.m.
2009/6/19 Krzysztof Foltman <wdev(a)foltman.com>om>:
Stefano D'Angelo wrote:
But you would have to know the float values in advance...
You're right. Well, I vote for the extra
function and leaving descriptor
untouched too.
What if that extra function was more of "get textual representation of a
particular float value" (see: Buzz MDK) instead of "get all strings"?
Added bonus: we could use it to provide textual
representations of
non-enums.
Well, if we use something like what I wrote yesterday, you could do
that already (just call it port_labels instead of port_enum_values, et
voila ;-)
Stefano
8:35 a.m.
Stefano D'Angelo wrote:
I'm talking about a label box displayed next to a knob here, not a combo
box. The combo box could still be used if the parameter had an integer
hint (and reasonable range, perhaps). In such a situation, you know the
float values in advance - those are 0..UpperLimit (-:
This way, a plugin could provide appropriate formatting (with relevant
number of decimal places) for each parameter separately. They could also
decide to format some values differently (to render 0 as a text "none"
for example, or to increase the number of decimal places for small
values without using a scientific notation).
What if that
extra function was more of "get textual representation of a
particular float value" (see: Buzz MDK) instead of "get all strings"?
But you would have to know the float values in advance... Well, if we use something like what I wrote yesterday,
you could do
that already (just call it port_labels instead of port_enum_values, et
voila ;-)
Explain, please?
If you mean an exported function like:
const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
float value);
it's more or less what I was talking about.
It still needs some additional specification. One missing thing is the
"lifecycle" of the returned memory block - like "it's valid until the
next call to ladspa_format_value".
Another is if it's allowed to return NULL when no custom formatting is
provided. I'd say it should be, for simplicity of a plugin. Also, it may
make sense to allow the host to assume that if a plugin returned NULL
for a specific port once, it will always return NULL for that port, so
that it doesn't need to call ladspa_format_value for that port in future.
Yet another question is if it's only usable if the "enum" port hint is
set. I think it's not, because the "enum" hint would still distinguish
between render-as-knob-like and render-as-combo-box-like situations. The
"this port is an enum and should be displayed as list of options"
capability is almost orthogonal to "this port has a custom string
renderer" capability. At least, 3 out of 4 values of those 2 bits are
very useful, and the remaining one (enum with no custom texts) isn't
harmful in any way.
Krzysztof
8:49 a.m.
2009/6/19 Krzysztof Foltman <wdev(a)foltman.com>om>:
Stefano D'Angelo wrote:
I'm talking about a label box displayed next to a knob here, not a combo
box. The combo box could still be used if the parameter had an integer
hint (and reasonable range, perhaps). In such a situation, you know the
float values in advance - those are 0..UpperLimit (-:
This way, a plugin could provide appropriate formatting (with relevant
number of decimal places) for each parameter separately. They could also
decide to format some values differently (to render 0 as a text "none"
for example, or to increase the number of decimal places for small
values without using a scientific notation).
I do totally agree, and in fact what I was suggesting looks like:
struct {
float value;
const char *name;
} ladspa_port_label;
struct ladspa_port_label ** ladspa_get_port_labels(unsigned long
descriptor_index, unsigned long port_index);
This is completely orthogonal to the enum hint, and you don't have to
ask for specific float values (I repeat, if the host is going to ask
for specific values, it should know somehow which values to ask for,
which is not good for non-integer, enum and/or non bounded ports).
Stefano
What if
that extra function was more of "get textual representation of a
particular float value" (see: Buzz MDK) instead of "get all strings"?
But you would have to know the float values in advance... Well, if we use something like what I wrote
yesterday, you could do
that already (just call it port_labels instead of port_enum_values, et
voila ;-)
Explain, please?
If you mean an exported function like:
const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
float value);
it's more or less what I was talking about.
It still needs some additional specification. One missing thing is the
"lifecycle" of the returned memory block - like "it's valid until the
next call to ladspa_format_value".
Another is if it's allowed to return NULL when no custom formatting is
provided. I'd say it should be, for simplicity of a plugin. Also, it may
make sense to allow the host to assume that if a plugin returned NULL
for a specific port once, it will always return NULL for that port, so
that it doesn't need to call ladspa_format_value for that port in future.
Yet another question is if it's only usable if the "enum" port hint is
set. I think it's not, because the "enum" hint would still distinguish
between render-as-knob-like and render-as-combo-box-like situations. The
"this port is an enum and should be displayed as list of options"
capability is almost orthogonal to "this port has a custom string
renderer" capability. At least, 3 out of 4 values of those 2 bits are
very useful, and the remaining one (enum with no custom texts) isn't
harmful in any way.
9:33 a.m.
Stefano D'Angelo wrote:
I do totally agree, and in fact what I was suggesting
looks like:
struct {
float value;
const char *name;
} ladspa_port_label;
struct ladspa_port_label ** ladspa_get_port_labels(unsigned long
descriptor_index, unsigned long port_index);
We are talking about two different things here.
You've described an API to return specific, named points within a range.
Kind of tick marks on a slider, with associated labels. So that you can
have a slider that has "cold" at zero value, "cool" at 25% and
"hot" at
100%. Is that right? The same API could also be used for returning
values and descriptions for enum ports (but not continuous ports, as it
would require about 2^32 port labels :) ).
On the other hand, I'm talking about a basic custom float-to-string
function. Something I could implement so that cutoff frequency for my
plugin could be formatted as "%0.0f Hz", while the delay time could be
formatted as "%0.2fms" for small values and "%0.0fms" for large
values.
Also, I could use it to format 0 as "Lowpass", 1 as "Highpass", etc.,
in
an integer port that I use for filter type. Which I could, also, mark as
"this is enum" with a sort of new hint we were talking about previously.
So far, I've seen more uses for formatting continuous values (a little
label next to a knob) than providing tick marks for continuous values.
However, there's a relatively simple solution to have both:
// this gives us text-to-string for arbitrary floats (side effect of
which is being able to implement enums)
const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
float value);
// this tells us which float values have "interesting" meaning
void ladspa_get_scalepoints(LADSPA_Descriptor *descriptor, int port, /*
[out] */ float **values, /* [out] */ int *values_count);
It may seem *very slightly* less efficient, but that should be OK, as
it's a microseconds-range difference in non-RT code.
For "normal" enums and custom-rendered parameters you'd only need the
first function anyway.
For completeness (I'm probably starting a flamewar here) we might also
have a reverse function, like:
float ladspa_parse_value(LADSPA_Descriptor *descriptor, int port, const
char *value, const char **error);
which would allow to convert user-entered values (like delay times in
seconds, milliseconds, centuries, Hertz etc. - or frequency ratios in
cents, semitones, octaves...) to a float value expected by given port,
optionally returning an error message if the text value is illegal.
Krzysztof
9:45 a.m.
2009/6/19 Krzysztof Foltman <wdev(a)foltman.com>om>:
Stefano D'Angelo wrote:
Ah, now I understand. Well, I have nothing against this ;-)
A little note, though: wouldn't it be better to pass this functions
the descriptor index rather than the descriptor pointer? (This really
is subjective taste, I guess).
Other than that, maybe you could also pass the plugin instance (should
be optional) to ladspa_parse_value() and ladspa_format_value(), just
in case the plugin might want to do the operations differently on a
current state basis (I don't know if this actually makes sense, but
I'm tossing this out just to know what you think about it).
Stefano
I do totally agree, and in fact what I was
suggesting looks like:
struct {
float value;
const char *name;
} ladspa_port_label;
struct ladspa_port_label ** ladspa_get_port_labels(unsigned long
descriptor_index, unsigned long port_index);
We are talking about two different things here.
You've described an API to return specific, named points within a range.
Kind of tick marks on a slider, with associated labels. So that you can
have a slider that has "cold" at zero value, "cool" at 25% and
"hot" at
100%. Is that right? The same API could also be used for returning
values and descriptions for enum ports (but not continuous ports, as it
would require about 2^32 port labels :) ).
On the other hand, I'm talking about a basic custom float-to-string
function. Something I could implement so that cutoff frequency for my
plugin could be formatted as "%0.0f Hz", while the delay time could be
formatted as "%0.2fms" for small values and "%0.0fms" for large
values.
Also, I could use it to format 0 as "Lowpass", 1 as "Highpass", etc.,
in
an integer port that I use for filter type. Which I could, also, mark as
"this is enum" with a sort of new hint we were talking about previously.
So far, I've seen more uses for formatting continuous values (a little
label next to a knob) than providing tick marks for continuous values.
However, there's a relatively simple solution to have both:
// this gives us text-to-string for arbitrary floats (side effect of
which is being able to implement enums)
const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
float value);
// this tells us which float values have "interesting" meaning
void ladspa_get_scalepoints(LADSPA_Descriptor *descriptor, int port, /*
[out] */ float **values, /* [out] */ int *values_count);
It may seem *very slightly* less efficient, but that should be OK, as
it's a microseconds-range difference in non-RT code.
For "normal" enums and custom-rendered parameters you'd only need the
first function anyway.
For completeness (I'm probably starting a flamewar here) we might also
have a reverse function, like:
float ladspa_parse_value(LADSPA_Descriptor *descriptor, int port, const
char *value, const char **error);
which would allow to convert user-entered values (like delay times in
seconds, milliseconds, centuries, Hertz etc. - or frequency ratios in
cents, semitones, octaves...) to a float value expected by given port,
optionally returning an error message if the text value is illegal.
10:15 a.m.
Stefano D'Angelo wrote:
A little note, though: wouldn't it be better to
pass this functions
the descriptor index rather than the descriptor pointer? (This really
is subjective taste, I guess).
I'm already thinking of reusing the same thing for DSSI, and DSSI
indexes may be overlap with LADSPA indexes while referring to different
plugins - while the same isn't the problem when using descriptors
(they're either different or point to the same plugin).
Example: dssi_descriptor may return "Synth A" as index 0 and "Effect
A"
as index 1, while ladspa_descriptor will only return "Effect A" as index
0. So, the index 0 may refer to the synth or the effect depending on
context (LADSPA or DSSI). On the other hand, even if DSSI and LADSPA
reuse the same LADSPA_Descriptor (like it was the case in older versions
of Calf), both uses of this descriptor refer to the same plugin.
to ladspa_parse_value() and ladspa_format_value(),
just
in case the plugin might want to do the operations differently on a
current state basis (I don't know if this actually makes sense, but
I'm tossing this out just to know what you think about it).
I'm against doing it in this iteration - because state-dependent
conversion is actually a more complex problem, which may be solved some
time in the next 40 years. It makes sense, but benefit/risk ratio is
worse than for other things already being proposed (circular flag,
enums, or even my silly text-float conversion).
Why is it more complex? It's because it makes it necessary to have
things like inter-parameter dependencies (to be able to specify that,
for example, port "filter type" affects the enum labels of "filter
rolloff", or that change in a port called "delay unit" from seconds to
samples should trigger a redraw of labels of ports called "delay length
(L)" and "delay length (R)"). It's a whole new can of worms, one that
I
don't *need* opened now. And if we do it without worrying about
dependencies, we end up with UI glitches (labels out of sync with
current state), or inefficiency like requerying all the enum-capable
ports for all the enum values after any port value change, just in case
any of them changed due to state change.
Krzysztof
11:17 a.m.
2009/6/19 Krzysztof Foltman <wdev(a)foltman.com>
Ok #2.
Stefano
Stefano D'Angelo wrote:
Ok.
A little note, though: wouldn't it be better
to pass this functions
the descriptor index rather than the descriptor pointer? (This really
is subjective taste, I guess).
I'm already thinking of reusing the same thing for DSSI, and DSSI
indexes may be overlap with LADSPA indexes while referring to different
plugins - while the same isn't the problem when using descriptors
(they're either different or point to the same plugin).
Example: dssi_descriptor may return "Synth A" as index 0 and "Effect
A"
as index 1, while ladspa_descriptor will only return "Effect A" as index
0. So, the index 0 may refer to the synth or the effect depending on
context (LADSPA or DSSI). On the other hand, even if DSSI and LADSPA
reuse the same LADSPA_Descriptor (like it was the case in older versions
of Calf), both uses of this descriptor refer to the same plugin. to
ladspa_parse_value() and ladspa_format_value(), just
in case the plugin might want to do the operations differently on a
current state basis (I don't know if this actually makes sense, but
I'm tossing this out just to know what you think about it).
I'm against doing it in this iteration - because state-dependent
conversion is actually a more complex problem, which may be solved some
time in the next 40 years. It makes sense, but benefit/risk ratio is
worse than for other things already being proposed (circular flag,
enums, or even my silly text-float conversion).
Why is it more complex? It's because it makes it necessary to have
things like inter-parameter dependencies (to be able to specify that,
for example, port "filter type" affects the enum labels of "filter
rolloff", or that change in a port called "delay unit" from seconds to
samples should trigger a redraw of labels of ports called "delay length
(L)" and "delay length (R)"). It's a whole new can of worms, one that
I
don't *need* opened now. And if we do it without worrying about
dependencies, we end up with UI glitches (labels out of sync with
current state), or inefficiency like requerying all the enum-capable
ports for all the enum values after any port value change, just in case
any of them changed due to state change.
12:53 p.m.
Krzysztof Foltman wrote:
// this gives us text-to-string for arbitrary floats
(side effect of
which is being able to implement enums)
const char *ladspa_format_value(LADSPA_Descriptor *descriptor, int port,
float value);
// this tells us which float values have
"interesting" meaning
void ladspa_get_scalepoints(LADSPA_Descriptor *descriptor, int port, /*
[out] */ float **values, /* [out] */ int *values_count);
For completeness (I'm probably starting a flamewar
here) we might also
have a reverse function, like:
float ladspa_parse_value(LADSPA_Descriptor *descriptor, int port, const
char *value, const char **error);
I'd be very happy to see this functionality too.
This (for me) would allow the removal of just about all parameter conversions
from the run function and just do them for display. (ie keep parameters native
as I don't have to worry about exposing internal values to users anymore). It
actually solves a whole lot of issues as we don't have to rely on hints to fine
tune the display of parameters.
While ideas are being tossed about, here are some more...
Do you think it would be possible to give the plugins some mechanism to
interrogate the host without breaking compatibility with ladspa v1.1? The things
I'd like to be able to find out about a host is for example:
* The current time signature and tempo (can be null when irrelevant)
* The language of the users environment (since we can format the parameters now)
* The application's name & version
* The application's ladspa version
//HostItems
//values
#define LADSPA_HOST_TEMPO 0x01 // 89.5
#define LADSPA_HOST_METER_BEATS 0x02 // the 3 in 3/4
#define LADSPA_HOST_METER_LENGTH 0x03 // the 4 in 3/4
#define LADSPA_HOST_LADSPA_MAJOR 0x04 // 1
#define LADSPA_HOST_LADSPA_MINOR 0x05 // 1
//strings
#define LADSPA_HOST_NAME 0x10 // "Crazy App"
#define LADSPA_HOST_VERSION 0x11 // "0.1.5"
#define LADSPA_HOST_LANGUAGE 0x12 // "en_AU.UTF-8"
#define LADSPA_HOST_LADSPA_VERSION 0x13 // "1.1"
float ladspa_get_host_value(LADSPA_Descriptor *descriptor, int HostItem)
const char *ladspa_get_host_string(LADSPA_Descriptor *descriptor, int HostItem)
The other thing I'd like to see is factory presets in RDF format. correct me if
I'm wrong but the current rdf schema only allows for preset "control ports"
which associate a preset name with an index. the actual values are "elsewhere"
(usually in code).
I mean something more like this (pseudo code)
<ladspa:Presents rdf:about="&ladspa;9999">
<ladspa:PresetDef rdf:value="0" ladspa:hasLabel="Sick Delay">
<ladspa:ControlValues>
<ladspa:Control rdf:about="&ladspa;9999.0" rdf:value="1"
/>
<ladspa:Control rdf:about="&ladspa;9999.1"
rdf:value="0.4" />
<ladspa:Control rdf:about="&ladspa;9999.2" rdf:value="99"
/>
<ladspa:Control rdf:about="&ladspa;9999.3" rdf:value="-6"
/>
</ladspa:ControlValues>
</ladspa:PresetDef
<ladspa:PresetDef rdf:value="1" ladspa:hasLabel="Long Delay">
<ladspa:ControlValues>
<ladspa:Control rdf:about="&ladspa;9999.0" rdf:value="1"
/>
<ladspa:Control rdf:about="&ladspa;9999.1"
rdf:value="2.5" />
<ladspa:Control rdf:about="&ladspa;9999.2" rdf:value="0"
/>
<ladspa:Control rdf:about="&ladspa;9999.3" rdf:value="0"
/>
</ladspa:ControlValues>
</ladspa:PresetDef>
</ladspa:Presents>
With some sort of standardised format we'd also be able to share user generated
presets between applications. (and each other)
regards,
Fraser
2:01 p.m.
Fraser wrote:
I'd be very happy to see this functionality too.
This (for me) would allow the removal of just about all parameter conversions
from the run function and just do them for display. (ie keep parameters native
as I don't have to worry about exposing internal values to users anymore). It
actually solves a whole lot of issues as we don't have to rely on hints to fine
tune the display of parameters.
Such a change could also give you problems if you expose
implementation-defined values (as opposed to real-life-compatible units)
to users. Think of backward compatibility, for example.
While ideas are being tossed about, here are some
more...
Be careful: I can't speak for everyone, but after years of stagnation it
would be nice to get a useful 1.2 out of the door without trying to cram
every possible good idea into it.
On the other hand, I'm definitely going to push for more improvements.
Just let's finalize 1.2 first, before everyone involved exceeds their
quota of give-a-damn ;)
Some ideas about discovery (which I *wouldn't* like to put into v1.2):
1. Define a plugin exported function (or a set of those) that need to be
called to notify the plugin about functionality it implements; which
will affect the set of descriptors that ladspa_descriptor will return
(i.e. host calls a plugin function called ladspa_host_version(1, 5); so
that plugin knows to return the plugins that require LADSPA v1.5 to be
implemented by the host)
This is actually dangerous in context of multiple hosts within same
process, and contrary to intuition, this situation may happen (say,
LADSPA plugins loaded into Ingen either directly or as LV2 via NASPRO
wrapper; )
2. Provide a new discovery function (say, ladspa15_descriptor), with
additional parameters that pass at least the version number implemented
by the host, and maybe some callback mechanism that can be used to
obtain information about the host.
Or alternatively, we can use some sort of RDF-based discovery mechanism,
preferably using some human-friendly notation. I've heard Turtle is
rather nice from that point of view ;)
Do you think it would be possible to give the plugins
some mechanism to
interrogate the host without breaking compatibility with ladspa v1.1? The things
I'd like to be able to find out about a host is for example:
* The current time signature and tempo (can be null when irrelevant)
These may be control ports with special hints, or special name, or some
transport related callback. It should be done reasonably soon, but it
shouldn't be done in v1.2 IMHO.
(I want it for Vintage Delay and other things, too!)
* The language of the users environment (since we can
format the parameters now)
The language can be read via getenv() - you may want to keep it simple :)
The host name - I wouldn't push for or against that.
Factory presets are important, too, but it proved to be a contentious
issue more than one time already, and you probably don't want to wait
until everyone agrees or stops giving a damn ;). If I had my way, I'd
probably avoid RDF or even XML, but that's, again, a flamewar waiting to
happen.
Krzysztof
8:14 p.m.
On Fri, 2009-06-19 at 19:00 +0100, Krzysztof Foltman wrote:
Factory presets are important, too, but it proved to
be a contentious
issue more than one time already, and you probably don't want to wait
until everyone agrees or stops giving a damn ;). If I had my way, I'd
probably avoid RDF or even XML, but that's, again, a flamewar waiting to
happen.
Is there such a thing as a LADSPA change that isn't a flamewar waiting
to happen? :)
-dr
10:18 p.m.
Krzysztof Foltman wrote:
fair play, it was late and I was overly enthusiastic :)
does anyone have access to ladspa.org? perhaps these and other ideas can be
noted in some sort of a roadmap?
regards,
Fraser
Such a change could also give you problems if you
expose
implementation-defined values (as opposed to real-life-compatible units)
to users. Think of backward compatibility, for example.
good point.
While ideas
are being tossed about, here are some more...
Be careful: I can't speak for everyone, but after years of stagnation it
would be nice to get a useful 1.2 out of the door without trying to cram
every possible good idea into it. 
18 Jun
18 Jun
5:24 p.m.
Hi,
On Thursday 18 June 2009 23:16:53 Tim Goetze wrote:
[Stefano D'Angelo]
But if the plugin is v1.2 and the host is v1.1 doesn't this mean the host only
used v1.1 at compile time? Then on copying the struct or on doing pointer-
arithmetic it will only know the old size of the struct and definitely copy
garbage or incomplete data for plugins of v1.2...
Sounds pretty BIC to me.
Arnold
Note: a weird host could copy make a copy of the
descriptors (I see
nothing claiming this should not happen in the header file), thus ABI
would be broken... this could maybe happen in LADSPA hosts written in
non-C languages (why does Java come to my mind?).
No, it's not a problem. A
host that does this is just treating the
plugin as a 1.1 version and ignoring the extra fields of the struct,
which is completely legal and causes no problems whatsoever.
5:43 p.m.
On Thu, Jun 18, 2009 at 11:23:52PM +0200, Arnold Krille wrote:
But if the plugin is v1.2 and the host is v1.1
doesn't this mean the host only
used v1.1 at compile time? Then on copying the struct or on doing pointer-
arithmetic it will only know the old size of the struct and definitely copy
garbage or incomplete data for plugins of v1.2...
Sounds pretty BIC to me.
Not that I would advocate adding things to the descriptor,
but this can't happen unless the host is broken anyway.
- if a host is 1.1 it will only copy the 1.1 parts,
- and not expect or use anything else.
It would only go wrong if a host would assume
that it can increment a descriptor pointer to
get the next one. But that would be illegal
anyway, as the plugin is not required to keep
descriptors in an array. It has to provide a
function returning an descriptor given an
index, and hosts are supposed to use that
and assume nothing else.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
20 Jun
20 Jun
8:07 a.m.
Hi Jörn,
I've just discovered this thread (and haven't found time to go through
the tail of it). I just wanted to add that we (clam developers at
BarcelonaMedia) are facing the same problem for the 3D audio systems,
and so we'd clearly advocate for having this functionality -- either
being Ladspa 1.2 or LV2 extension(?), I have no strong opinion on that.
However we currently workaround this problem by doing the following: we
always define the acoustic scene outside ardour (in blender for
example), and then we export to the ardour automations writing directly
in the ardour xml session. By doing this you can control the problem
since you can detect the time your control would have a circular jump
(say from -180 to +180). There you insert two controls (-180 and 180)
separated with the minimum time unit.
Regards
Pau
El dj 18 de 06 de 2009 a les 18:28 +0200, en/na Jörn Nettingsmeier va
escriure:
hi everybody!
as discussed in another thread, i would like to propose a new LADSPA
release 1.2, which should include the following changes:
1. addition of a port range hint flag LADSPA_HINT_PERIODIC to denote
periodic behaviour of a control port to be added to the
LADSPA_PortRangeHintDescriptor bit field.
if present, both LADSPA_HINT_BOUNDED_BELOW and
LADSPA_HINT_BOUNDED_ABOVE must be specified as well. moreover,
both LowerBound and UpperBound must be present in the corresponding
LADSPA_PortRangeHint struct.
the presence of LADSPA_HINT_PERIODIC implies that LowerBound is
equivalent to UpperBound.
hosts should consider displaying a widget that reflects the periodic
nature of the corresponding control value, such as a rotary control.
hosts that interpolate between control values defined by the user
(such as automation points in a DAW) should take into account that
the shortest path between two given values might cross the
boundary defined by LowerBound resp. UpperBound and behave
accordingly.
usage example: soundfield rotators, circular panners
2. addition of a port range hint flag LADSPA_HINT_ENUMERATED to inform
hosts that an integer-type port (as denoted by LADSPA_HINT_INTEGER)
should be annotated with a set of labels rather than numbers.
LADSPA_HINT_ENUMERATED mandates the following:
LADSPA_HINT_INTEGER is set.
LADSPA_HINT_BOUNDED_BELOW and LADSPA_HINT_BOUNDED_ABOVE must be set.
in LADSPA_PortRangeHint, LowerBound must be 0, UpperBound must be >0.
the number of labels provided must be equal to (UpperBound - 1).
some of these mandatory settings are redundant and could be handled
as being implicit.
however, for the sake of backwards compatibility and to to allow
older hosts to display a meaningful UI even if they don't implement
the new flag yet, all these items MUST be set.
as to the location of the actual enum of labels: fons adriaensen
suggests adding them to the end of the PortNames array.
this implies that for multiple enum-labelled controls, the labels
would have to be concatenated and the host would have to tell them
apart by keeping track of the corresponding UpperBound offsets, which
might become a little messy. your comments are welcome.
best,
jörn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
5426
days inactive
5431
days old
linux-audio-dev@lists.linuxaudio.org
43 comments
12 participants
participants (12)
-
Arnold Krille -
Damon Chaplin -
David Robillard -
Fons Adriaensen -
Fraser -
Jörn Nettingsmeier -
Krzysztof Foltman -
Luis Garrido -
Pau Arumí -
Stefan Kost -
Stefano D'Angelo -
Tim Goetze