7 Mar
2004
7 Mar
'04
8:50 p.m.
attached you'll please find three files:
* a patch moving ladspa.h 1.1 to 2.0
* a program showing how a host evaluates 2.0 extensions
* a thoroughly documented example plugin making use of the extensions
changes to the patch with respect to the last version include
consolidation of the extended port info into a dedicated structure.
also included is a warning note concerning the deprecation of the
1.1 default value hints and some minor clarifications.
the patch defines HINT_MOMENTARY as asked by Taybin and Steve. it
also credits Taybin now (Steve already being credited).
-
the example plugin is written with the intention to show, in all its
sometimes gory detail, how ladspa works 'from the plugin side'. the
plugin is fully operational in hosts implementing either version of
the standard. (it doesn't even sound so bad at all :)
there are a number of more elegant ways to accomplish what the plugin
source does, but these have all been ignored for the sake of showing
exactly how things are coming together in ladspa.
-
if you expect the extension to make a plugin author's life harder by a
significant amount, i would like to ask you to go over the source code
of the example plugin and see for yourself.
all the places where the plugin refers to the 2.0 incarnation have
been marked as such. i'm confident you'll agree that words like
'invasive', 'incomprehensible', 'bloated' or
'complicating' are not
doing the extension justice.
i would also like you to consider that it is up to you, either plugin
or host author, to altogether ignore the extension and still come up
with something perfectly useful. you can always extend your work to
make use of the extension at a later date. all this takes is added
code, with no changes to what you already have.
-
my apologies offered for the obnoxious use of the '2.0' version tag
for this proposal. for sheer lack of fantasy, typing laziness and a
number of other bad habits, i couldn't come up with something better.
amicalement,
tim
ps: it is hoped that the example plugin source will be helpful to
aspiring plugin authors, no matter the fate of the extension proposal.
8 Mar
8 Mar
2:31 a.m.
On Mon, Mar 08, 2004 at 01:39:36AM +0100, Tim Goetze wrote:
attached you'll please find three files:
* 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.
Having thought about it some more I think this way of presenting defaults
is fine, but I'm still not happy with the way latency or units are
specified.
If latency can't be changed programatically then lets not have it in the
struct (few hosts can use it anyway, and they all use RDF), if it can be
changed programatically then it should be a well-known port, as it is now
be convention (but possibly with a different label).
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.
You know my feelings on enumerations :)
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.
- Steve
10:29 a.m.
Steve Harris wrote:
Having thought about it some more I think this way of presenting defaults
is fine, but I'm still not happy with the way latency or units are
specified.
If latency can't be changed programatically then lets not have it in the
struct (few hosts can use it anyway, and they all use RDF), if it can be
changed programatically then it should be a well-known port, as it is now
be convention (but possibly with a different label).
Fixed latency is not a big issue because a plugin can report the maximum
latency it could ever reach, and if the actual latency is lower it can
artificially delay its output internally. But i think this is ugly,
particularly because of the fact that we already have a working setup
with the "latency" control output which allows for changing latency as
well -- and this does make sense, since latency may depend on sampling
rate in a large number of cases, and since sample rate may vary almost
an order of magnitude, i think it would be suboptimal to impose a
needless delay on the whole processing line.
As i said before, i support everything else in Tim's proposal, which is
(to me) well-thought and clean. I will adapt my reverb to make use of
the new features as soon as i have a little time (few days).
Tom
10:59 a.m.
On Mon, Mar 08, 2004 at 03:22:57 +0100, Tom Szilagyi wrote:
Fixed latency is not a big issue because a plugin can
report the maximum
latency it could ever reach, and if the actual latency is lower it can
artificially delay its output internally. But i think this is ugly,
particularly because of the fact that we already have a working setup
with the "latency" control output which allows for changing latency as
well -- and this does make sense, since latency may depend on sampling
rate in a large number of cases, and since sample rate may vary almost
an order of magnitude, i think it would be suboptimal to impose a
needless delay on the whole processing line.
The problem is that if your plugin does have variable lantecy then the
host cant really support it anyway - it cant tell what the latency is at
any particular instant in time and it cant change the latency compensation
without introducing distortion into the output signal.
I have tried to write a host that did dynamic latency compensation without
distortion and gave up and implemented a version of the plugin with fixed
latency :) Its probably possible if your willing to let a bit of zipper
noise pass, but for JAMin that wasn't acceptable.
I'm not against variable latency per se (its what I support now), I'm just
not sure that its worth it.
Your point about sample rate or system dependency is well made. I'm not
sure how comman that is, but that could be an issue.
- Steve
11:28 a.m.
[Tom Szilagyi]
Fixed latency is not a big issue because a plugin can
report the maximum
latency it could ever reach, and if the actual latency is lower it can
artificially delay its output internally. But i think this is ugly,
particularly because of the fact that we already have a working setup
with the "latency" control output which allows for changing latency as
well -- and this does make sense, since latency may depend on sampling
rate in a large number of cases, and since sample rate may vary almost
an order of magnitude, i think it would be suboptimal to impose a
needless delay on the whole processing line.
ok, after going over tap_limiter.c in detail i see the point of
communicating latency information to the host at runtime (and neither
a dedicated descriptor member, nor RDF will ever succeed in trying to
accommodate the behaviour).
using a dedicated CONTROL | OUTPUT port for this purpose is indeed
a very sensible option.
consequently, all we need do is document the "latency" port in
ladspa.h i think.
i would like to make life easier for host authors by requiring plugins
to never vary latency after instantiation (recall that instantiation
sets the sample rate, after which it remains fixed).
since the latency number is fixed throughout the plugin lifecycle, the
tap_limiter behaviour of writing to the 'latency' port once, namely as
soon as it is connected, seems the most sensible option.
-
a much cleaner way to do this would be a 'get_latency()' method,
required to return the same figure throughout the plugin lifecycle.
we can still do that and not require the 'latency' port hack.
what's your thought on this?
amicalement,
tim
11:43 a.m.
New subject: Latency indication (was Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff))
On Mon, Mar 08, 2004 at 04:18:11 +0100, Tim Goetze wrote:
ok, after going over tap_limiter.c in detail i see the
point of
communicating latency information to the host at runtime (and neither
a dedicated descriptor member, nor RDF will ever succeed in trying to
accommodate the behaviour).
using a dedicated CONTROL | OUTPUT port for this purpose is indeed
a very sensible option.
consequently, all we need do is document the "latency" port in
ladspa.h i think.
Yes, but we need to think carefully about the name, "_latency" or
".latency" might be a better choice, with a note that hosts should ignore
_/. prefixed ports that they do not understand.
When we thrashed it out Paul and I did consider this, but I cant remeber
why we went with plain "latency" in the end. Paul?
a much cleaner way to do this would be a
'get_latency()' method,
required to return the same figure throughout the plugin lifecycle.
we can still do that and not require the 'latency' port hack.
I dont think thats cleaner - it requires that atleast the avticate method
has been called (preferably run()) but without an enforced requirement for
it, whereas writing the value to a port physically requires that run() or
activate() be called. Also its inherently synchronous with the run()
cycle, being set during each call.
- Steve
noon
New subject: Latency indication (was Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff))
On Mon, Mar 08, 2004 at 03:38:17PM +0000, Steve Harris wrote:
Yes, but we need to think carefully about the name,
"_latency" or
".latency" might be a better choice, with a note that hosts should ignore
_/. prefixed ports that they do not understand.
Agreed 100%. Votes++ for _latency.
--
Fons
1:48 p.m.
New subject: Latency indication (was Re: [linux-audio-dev] +momentary, consolidated (ladspa.h.diff))
Yes, but we need to think carefully about the name,
"_latency" or
".latency" might be a better choice, with a note that hosts should ignore
_/. prefixed ports that they do not understand.
i would prefer
#define LADSPA_LATENCY_PORT_NAME "_wotever"
or something similar.
11:54 a.m.
Tim Goetze wrote on Mon, 08-Mar-2004:
since the latency number is fixed throughout the
plugin lifecycle, the
tap_limiter behaviour of writing to the 'latency' port once, namely as
soon as it is connected, seems the most sensible option.
This is not true for several of the plugins that have a "latency"
output port. The latency value is determined in some plugins
by a combination of the sample rate AND one or more control ports
(lookahead time, etc) which can be changed at any time. In practice,
these control parameters will rarely be changed by the host during the time that
the latency value will be used for compensation, but forcing a
read-once at instantiation will not be a viable solution either.
The way it is now seems fine to me, for the intended purpose.
Ardour, for instance evaluates path latency upon transport start,
so any changes to the latency value in plugins are ignored
while rolling anyway.... however we may not be calling instantiate
at that time.
jlc
10:58 a.m.
[Steve Harris]
On Mon, Mar 08, 2004 at 01:39:36AM +0100, Tim Goetze
wrote:
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.
[...]
* 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. 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
11:34 a.m.
On Mon, Mar 08, 2004 at 03:48:22 +0100, Tim Goetze wrote:
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.
[Steve Harris]
2.0 implies a substantial rewrite and no backward compatibility.
On Mon, Mar 08, 2004 at 01:39:36AM +0100, Tim
Goetze wrote:
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. * 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. in the end, it's just a number, so i won't
insist if more votes
against it will be heard.
Fair enough.
[...]
There are allready a /lot/ of plugins with unit names in brackects at the
end of port names. You can't parse them out, but why would you? What are
you going to do with the unit name other than display it, unless you have
metadata?
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.
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 I wanted to use metadata to describe units of parameters (I dont think
I do right now) I would want to do a lot more than just name them.
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.
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.
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.
- Steve
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.
2:04 p.m.
On Mon, Mar 08, 2004 at 05:51:28 +0100, Tim Goetze wrote:
i'm trying to follow your previous argument of 'logically connected'.
for plugins with many ports, this is very convenient.
I dont think that scale markings, / enumerations, defaults and units are
logically connected to the same extent that upper and lower bounds are.
That is a matter of opinion of course. I agree its more convienient, but I
really dont like the idea of padding out the PortFoo struct(s) to allow
for exansion.
By contrast the port descriptor hints and names are all members of the
plugin struct - its only upper and lower bounds that are in a seperate
struct.
- Steve
[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".
Thats true, but I dont think the gain is worth the pain of loosing the
units display in 1.1 hosts (or having a seperate port initialiser for
1.1) and revamping all 250 plugins (or however many it is). Especially as
we currently have zero embedded 2x16 LCD hosts.
If we were designing from scratch it might be a nice idea, but I would
want something (optionally) more complete than just a label. You dont know
wether its supposed to be prefix of postfix and how it should be padded,
what the 1000's or 1000ths units are, etc, etc. So it only buys you a
little more flexibility.
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. and to repeat: if you don't want units to appear
in the plugin
sources, why are you satisified with "Frequency (Hz)"?
I'm only satisfied with it because its allready widely used, in in
practice its bascily OK. Not ideal, but OK. Even I have to be pragmatic
sometimes :)
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. 
5:29 p.m.
On Mon, Mar 08, 2004 at 05:58:48PM +0000, Steve Harris wrote:
I dont think that scale markings, / enumerations,
defaults and units are
logically connected to the same extent that upper and lower bounds are.
That is a matter of opinion of course.
Well, for me ENUMs on an integer param that maps to a multiway switch, a set
of radio buttons or a menu are not 'meta'. Without them you have *no* idea what
the switch is doing, so they seem IMHO as essential as Min / Max on a slider.
Same for TRIGGER, the host needs to know this, but then I suspect most triggers
would never be in a GUI but rather external or from another module.
Scale points on a floating point param are an entirely different matter even
if they could be mapped to a similar data structure - that's a coincidence and
doesn't mean anything. Separate unit strings are, for me, a luxury. I agree
that both could be in the RDF only. And other than AUDIO / CONTROL which are
not compatible at the 'physical' level, I think there should be no port typing
in LADSPA.
As to defaults, the current system is limited, but for me it is sufficient.
The only thing defaults should be used for is to make sure the plugin start
in a sensible state. Anything beyond this can become a preset, if required.
--
Fons
9 Mar
9 Mar
4:48 a.m.
On Mon, Mar 08, 2004 at 10:29:51 +0100, Fons Adriaensen wrote:
On Mon, Mar 08, 2004 at 05:58:48PM +0000, Steve Harris
wrote:
I think theres some confusion about what the meta- in metadata means, it
doesnt imply "lesser" or optional - it just reflects the level of
abstraction.
I dont think that scale markings, / enumerations,
defaults and units are
logically connected to the same extent that upper and lower bounds are.
That is a matter of opinion of course.
Well, for me ENUMs on an integer param that maps to a multiway switch, a set
of radio buttons or a menu are not 'meta'. Without them you have *no* idea what
the switch is doing, so they seem IMHO as essential as Min / Max on a slider.
Same for TRIGGER, the host needs to know this, but then I suspect most triggers
would never be in a GUI but rather external or from another module. Scale points on a floating point param are an entirely
different matter even
if they could be mapped to a similar data structure - that's a coincidence and
doesn't mean anything. Separate unit strings are, for me, a luxury. I agree
I disagree: if I have a control thats "wave, INTEGER where 1=sin, 2=tri,
3=sqa, 4=saw" and one which is the same less the INTEGER hint (ie. it
crossfades) then the enumeration points are no less importanti in the
non-INTEGER case.
that both could be in the RDF only. And other than
AUDIO / CONTROL which are
not compatible at the 'physical' level, I think there should be no port typing
in LADSPA.
I agree about no port typing.
The MOMENTARY hint is not (should not be) typing though - its just a hint
to let the host build a useful UI. There are use-cases. Ditto for
RANDOMIZABLE.
As to defaults, the current system is limited, but for
me it is sufficient.
The only thing defaults should be used for is to make sure the plugin start
in a sensible state. Anything beyond this can become a preset, if required.
I understand where you're coming from here. There are a few cases where
the current system fails (not many, and not seriously, but they are
there).
- Steve
7:13 a.m.
On Tue, Mar 09, 2004 at 10:30:09 +0100, Alfons Adriaensen wrote:
On Tue, Mar 09, 2004 at 08:43:18AM +0000, Steve Harris
wrote:
Yup, am_pitchshift
Plugin Name: "AM pitchshifter"
Plugin Label: "amPitchshift"
Plugin Unique ID: 1433
Maker: "Steve Harris <steve(a)plugin.org.uk>"
Copyright: "GPL"
Must Run Real-Time: No
Has activate() Function: No
Has deativate() Function: No
Has run_adding() Function: Yes
Environment: Normal or Hard Real-Time
Ports: "Pitch shift" input, control, 0.25 to 4, logarithmic
"Buffer size" input, control, 1 to 7, integer
"Input" input, audio
"Output" output, audio
"latency" output, control
buffer size defualt should be 3
(http://plugin.org.uk/ladspa-swh/docs/ladspa-swh.html#id1433), but theres
no way to specify that. Its not a huge problem, but it is a case of the
current API failing.
In general I like the fact that the hints encourage you to place the
default behavious in obvious places, but ocasionaly it bites you.
- Steve
I understand where you're coming from here.
There are a few cases where
the current system fails (not many, and not seriously, but they are
there).
Interesting. Do you have an example ?
8:57 a.m.
On Tue, Mar 09, 2004 at 08:43:18AM +0000, Steve Harris wrote:
I disagree: if I have a control thats "wave,
INTEGER where 1=sin, 2=tri,
3=sqa, 4=saw" and one which is the same less the INTEGER hint (ie. it
crossfades) then the enumeration points are no less importanti in the
non-INTEGER case.
OK, then we allow HINT_ENUMERATED for float ports as well, and provide
a string (or NULL pointer) for each integer in the range. I proposed this
before IIRC.
I think that in a case like this, you will always be able to map the
'important points' to integers.
--
FA
9:57 a.m.
[Alfons Adriaensen]
On Tue, Mar 09, 2004 at 08:43:18AM +0000, Steve Harris
wrote:
ok. since we don't have any code to base our judgement of this
proposal on, i'll quote an earlier post from you, where you are
referring to the strings describing specific parameter values:
I disagree: if I have a control thats "wave,
INTEGER where 1=sin, 2=tri,
3=sqa, 4=saw" and one which is the same less the INTEGER hint (ie. it
crossfades) then the enumeration points are no less importanti in the
non-INTEGER case.
OK, then we allow HINT_ENUMERATED for float ports as well, and provide
a string (or NULL pointer) for each integer in the range. I proposed this
before IIRC.
I think that in a case like this, you will always be able to map the
'important points' to integers. Appending the labels to the port names array looks very
clean to
me. The array becomes in effect an array that contains all strings
required - first the top level ones (port names), then the second
level (enum labels). This is not a dirty trick or an ad-hoc solution,
it could be generalised to higher levels.
this _is_ a dirty trick and an ad-hoc solution if ever there was one
if you ask me. generalizing this to higher levels gives me nausea.
besides, it has been shown that you need not limit yourself to double
usage of existing descriptor members to maintain binary compatibility.
i know you can do better.
vriendelijk,
tim
11:18 a.m.
On Tue, Mar 09, 2004 at 02:46:47PM +0100, Tim Goetze wrote:
Grouping all strings into a 'string pool' with some indexing scheme on
top is a very common idiom. See most object or library file formats,
symbol table algorithms, etc.
In this case, the strings are logically in a tree structure, with two
levels: 1. the port names, 2: the labels. If we would add support
for hierarchical menus instead of simple enumerations, the number of
levels would increase.
The order they are put in corresponds to a breadth-first traversal
of this tree. This is one of the standard algorithms to index tree
elements (the two other commonly used are depth-first and in-order).
It has the advantage (in this case) that elements are sorted by level,
so the portnames remain where they are now.
[Alfons Adriaensen]
>I think that in a case like this, you will always
be able to map the
>'important points' to integers.
ok. since we don't have any code to base our
judgement of this
proposal on, i'll quote an earlier post from you, where you are
referring to the strings describing specific parameter values:
1. I assume that everybody on this list knows what what an array
of string constants looks like in C. Otherwise, see ladspa.h.
It's the same array, it only becomes longer. That's all there is
to it, there no further 'code' required.
2. I fail to see the relation between the remark you quote, and your
comments below.
Appending the
labels to the port names array looks very clean to
me. The array becomes in effect an array that contains all strings
required - first the top level ones (port names), then the second
level (enum labels). This is not a dirty trick or an ad-hoc solution,
it could be generalised to higher levels.
this _is_ a dirty trick and an ad-hoc solution if ever there was one
if you ask me. generalizing this to higher levels gives me nausea. besides, it has been shown that you need not limit
yourself to double
usage of existing descriptor members to maintain binary compatibility.
It's not 'double usage' but generalisation, see above.
i know you can do better.
Sure.
--
FA
11:57 a.m.
[Alfons Adriaensen]
a string pool is ok per-se (although it's not an idea i prefer for
reasons already given), but certainly not one referenced by the name
'PortNames'.
i'm also clearly against requiring plugin and host coders to be
knowledgeable in compiler and binary object format implementation
and techniques. you can be glad if DSP people speak more than BASIC
to start with. :)
[...]
On Tue, Mar 09, 2004 at 02:46:47PM +0100, Tim Goetze
wrote:
understood. now please consider the implications for a host: it needs
to find the offset into the string array where the labels for the
first ENUMERATED port start. no problem, we use PortCount. then it
needs to compute how many labels (integer values inside that port's
range) to find out where the next port's value label enumeration
starts. and so on for every such port.
all this code needs to be written in every host, just because you
don't want to give fool-proof pointers to arrays terminated by a NULL
element? you must be kidding.
besides, on the plugin side you end up with a potentially huge array
of mostly unrelated strings, where index ordering and number is vital.
a welcome feeding place for bugs here, too.
i haven't seen such complicated data structuring practice since the
days of machine-language coding only. it reminds me more of a binary
file format spec than of a public API intended for general use.
[Alfons Adriaensen]
>I think that in a case like this, you will
always be able to map the
>'important points' to integers.
ok. since we don't have any code to base our
judgement of this
proposal on, i'll quote an earlier post from you, where you are
referring to the strings describing specific parameter values:
1. I assume that everybody on this list knows what what an array
of string constants looks like in C. Otherwise, see ladspa.h.
It's the same array, it only becomes longer. That's all there is
to it, there no further 'code' required. 2. I fail to see the relation between the remark you
quote, and your
comments below.
agreed, a case of bad quoting on my part. i was referring to the
consequences of your proposal, assuming they are clearly implied.
now that i have stated them, the relation becomes a little clearer
i hope.
this _is_ a
dirty trick and an ad-hoc solution if ever there was one
if you ask me. generalizing this to higher levels gives me nausea.
Grouping all strings into a 'string pool' with some indexing scheme on
top is a very common idiom. See most object or library file formats,
symbol table algorithms, etc. The order they are put in corresponds to a
breadth-first traversal
of this tree. This is one of the standard algorithms to index tree
elements (the two other commonly used are depth-first and in-order).
It has the advantage (in this case) that elements are sorted by level,
so the portnames remain where they are now.
whatever fancy name you choose to give it, it's still at least a hack
and certainly the wrong place to put it to me. :)
vriendelijk,
tim
1:06 p.m.
On Tue, Mar 09, 2004 at 04:46:58PM +0100, Tim Goetze wrote:
understood. now please consider the implications for a
host: it needs
to find the offset into the string array where the labels for the
first ENUMERATED port start. no problem, we use PortCount. then it
needs to compute how many labels (integer values inside that port's
range) to find out where the next port's value label enumeration
starts. and so on for every such port.
all this code needs to be written in every host, just because you
don't want to give fool-proof pointers to arrays terminated by a NULL
element? you must be kidding.
Be reasonable. This is not complicated at all. See code below.
besides, on the plugin side you end up with a
potentially huge array
of mostly unrelated strings, where index ordering and number is vital.
a welcome feeding place for bugs here, too.
If you know how to write the PortNames array, adding the label strings
is just the same. They are in the order you'd expect them to be.
i haven't seen such complicated data structuring
practice since the
days of machine-language coding only. it reminds me more of a binary
file format spec than of a public API intended for general use.
i'm also clearly against requiring plugin and host coders to be
knowledgeable in compiler and binary object format implementation
and techniques.
This is pure nonsense, and you know it.
--
FA
----------------->8--------------
// Being at work and with no ladspa.h available, there could
// be some errors. Of course this code is incomplete, but its
// only purpose is to show how the label strings are read.
const char * const *N = handle->Portnames;
const LADSPA_PortDescriptor *D = handle->PortDescriptors;
const LADSPA_PortRangeHint *H = handle->PorRangeHints;
int i, k, h, n;
float min, max;
k = handle->PortCount; // index of any labels
for (i = 0; i < handle->PortCount; i++)
{
if (D [i] & LADSPA_PORT_CONTROL)
{
h = H [i].HintDescriptor;
min = H [i].LowerBound;
max = H [i].UpperBound;
if (h & LADPSA_HINT_INTEGER)
{
if (h & LADSPA_HINT_ENUMERATED)
{
n = (int)(floor (max) - ceil (min)) + 1; // number of labels
create_widget_with_enums (N [i], min, max, n, N + k);
k += n; // index of next set of labels
}
else
{
create_widget_no_enums (N [i], min, max);
}
}
else
...
}
else
...
}
// So apart from the code that has to be there anyway if the
// LADSPA_HINT_ENUMERATED is to be supported, there are 3
// extra lines:
//
// k = handle->PortCount; // index of any labels
// n = (int)(floor (max) - ceil (min)) + 1; // number of labels
// k += n; // index of next set of labels
//
// Go ahead and call this complicated. Or object about the short
// variable names. Or the indentation style.
----------------->8--------------
2 p.m.
[Alfons Adriaensen]
On Tue, Mar 09, 2004 at 04:46:58PM +0100, Tim Goetze
wrote:
thanks for providing the code. i'll not argue it is not complete
seeing that it seems impossible to obtain ladspa.h or gcc from your
workplace. :)
without making an absolute estimate of the complexity of your snippet,
and presuming it will compile and work flawlessly, i think it is safe
to say it is more complex than the PortInfo proposal.
next, i would like you to consider that if this mechanism becomes
reality, we'll have to give a watertight explanation in the ladspa
header.
also still in dire need of explanation is the fact that an array is
referenced as 'PortNames' but contains data that will not fit this
name.
i do admit the mechanism is elegant, and makes for a compact object
file. but these are secondary virtues, with no good reason given why
they should preceed primary virtues: readability, simplicity, fool-
proof operation, versatility.
lastly, you still haven't given a good reason why non-integer values
should not be associated with labels.
amicalement,
tim
ps: i like your indentation style fwiw.
understood. now please consider the implications
for a host: it needs
to find the offset into the string array where the labels for the
first ENUMERATED port start. no problem, we use PortCount. then it
needs to compute how many labels (integer values inside that port's
range) to find out where the next port's value label enumeration
starts. and so on for every such port.
all this code needs to be written in every host, just because you
don't want to give fool-proof pointers to arrays terminated by a NULL
element? you must be kidding.
Be reasonable. This is not complicated at all. See code below.
3:37 p.m.
On Tue, Mar 09, 2004 at 06:49:46PM +0100, Tim Goetze wrote:
thanks for providing the code. i'll not argue it
is not complete
seeing that it seems impossible to obtain ladspa.h or gcc from your
workplace. :)
It's not impossible to get them, and in fact I'm using five versions
(for different targets) of g++ daily. It's just that I'm not paid to
do this during work hours, so I limited the code to the essential part.
In fact Alcatel Space paid for all the replies to your posts today.
without making an absolute estimate of the complexity
of your snippet,
and presuming it will compile and work flawlessly, i think it is safe
to say it is more complex than the PortInfo proposal.
But still trivially simple. If someone writing a host falls over this,
he will probably never reach the end. There are much more complicated
issues to deal with.
next, i would like you to consider that if this
mechanism becomes
reality, we'll have to give a watertight explanation in the ladspa
header.
Sure.
also still in dire need of explanation is the fact
that an array is
referenced as 'PortNames' but contains data that will not fit this
name.
"For historical reasons". It's in the good company of the 'gecos'
field in /etc/passwd for example.
i do admit the mechanism is elegant, and makes for a
compact object
file. but these are secondary virtues, with no good reason given why
they should preceed primary virtues: readability, simplicity, fool-
proof operation, versatility.
I never claimed compactness or versatility as a virtue. It *is* readable
and simple. Nothing in C is ever foolproof - an invalid pointer will
hit you no matter how you implement the enums. There's the demolition
tool to test for this.
lastly, you still haven't given a good reason why
non-integer values
should not be associated with labels.
As I said, it's a different problem. And your proposal is a clean way
to solve part of it. But IMHO it should be generalised, but then it
probably enters the RDF domain.
--
Fons
4:15 p.m.
[Fons Adriaensen]
on which i would rather like to see people concentrate. i'm also not
particularly happy with your 'trivially simple', and the sentence
following it. what may come easy to you can be hard for others, and
vice versa.
even if we retreat to such a weak excuse, this certainly doesn't
qualify for making life for new authors simpler (on which we seemed
to be in agreement).
also, even for seasoned developers, maintaining a combined
port names + n * (value labels) array can become a burden all too
easily i fear.
if you don't even see compactness as a virtue, there's only elegance
remaining to recommend your proposal. elegance at the cost of
increased complexity in understanding and implementation, no matter
how you look at it.
you have yet to prove it's a different problem, and tell us what
points need to be generalized beyond the solutions we have proposed.
amicalement,
tim
without making
an absolute estimate of the complexity of your snippet,
and presuming it will compile and work flawlessly, i think it is safe
to say it is more complex than the PortInfo proposal.
But still trivially simple. If someone writing a host falls over this,
he will probably never reach the end. There are much more complicated
issues to deal with. also still in
dire need of explanation is the fact that an array is
referenced as 'PortNames' but contains data that will not fit this
name.
"For historical reasons". It's in the good company of the 'gecos'
field in /etc/passwd for example. i do admit the
mechanism is elegant, and makes for a compact object
file. but these are secondary virtues, with no good reason given why
they should preceed primary virtues: readability, simplicity, fool-
proof operation, versatility.
I never claimed compactness or versatility as a virtue. It *is* readable
and simple. Nothing in C is ever foolproof - an invalid pointer will
hit you no matter how you implement the enums. There's the demolition
tool to test for this. lastly, you
still haven't given a good reason why non-integer values
should not be associated with labels.
As I said, it's a different problem. And your proposal is a clean way
to solve part of it. But IMHO it should be generalised, but then it
probably enters the RDF domain.
6:44 p.m.
New subject: [linux-audio-dev] SWITCHED versus ENUMERATED (was: +momentary, consolidated (ladspa.h.diff))
On Tue, Mar 09, 2004 at 09:05:16PM +0100, Tim Goetze wrote:
if you don't even see compactness as a virtue,
there's only elegance
remaining to recommend your proposal. elegance at the cost of
increased complexity in understanding and implementation, no matter
how you look at it.
It *is* compact, even if I didn't claim that as a virtue :-)
The complexity consist of knowing that the label strings follow
the port names. The implementation requires very little code, as
I have shown. So I do not agree with these comments.
you have yet to prove it's a different problem,
and tell us what
points need to be generalized beyond the solutions we have proposed.
It is different in the same way that C's switch() statement is different
from a series of if() tests on floating point values. Each has its own
sphere of application, and these do not really overlap. In the second
case for example, the value you test still has a meaning regardless of
the result of the test, and you should in general not test for equality.
The constants that a swicth() will test do not have to have any meaning
at all other than being an arbitrary number used to represent an option,
and are tested for strict equality.
As to generalisation, I already mentioned that additional fields could
be used to request a particular physical position of a scale point.
More generally, once a 'version' bit is introduced, you can in fact
change whatever you want, and go much beyond what you proposed. In that
case all open questions should be reviewed and a structured and unified
solution should be proposed.
--
Fons
7:03 p.m.
New subject: [linux-audio-dev] SWITCHED versus ENUMERATED (was: +momentary, consolidated (ladspa.h.diff))
On Tue, Mar 09, 2004 at 11:45:21 +0100, Fons Adriaensen wrote:
More generally, once a 'version' bit is
introduced, you can in fact
change whatever you want, and go much beyond what you proposed. In that
case all open questions should be reviewed and a structured and unified
solution should be proposed.
It may be more general to offer an additional exported function, eg
ladspa_descriptor_with_version where hosts can specify the version they
conform to, to allow future binary-incompatible versions. It also may be
a bad idea :)
- Steve
10:01 a.m.
On Tue, Mar 09, 2004 at 01:51:56 +0100, Alfons Adriaensen wrote:
On Tue, Mar 09, 2004 at 08:43:18AM +0000, Steve Harris
wrote:
When your dealing with phases or angles, it will be inconvienent. Even if
you use degrees, it will be anoying to have 360 (or 400, i18n :) points,
only 4 of which have labels.
Ditto for tape simulations, the speeds are 76, 38, 19 and 9.5 cm/s (30,
15, 7.5 and 3.75 inches/s).
Tim sent a mail a few days ago with some other examples where integers are
not the significnat points.
- Steve
I disagree: if I have a control thats "wave,
INTEGER where 1=sin, 2=tri,
3=sqa, 4=saw" and one which is the same less the INTEGER hint (ie. it
crossfades) then the enumeration points are no less importanti in the
non-INTEGER case.
OK, then we allow HINT_ENUMERATED for float ports as well, and provide
a string (or NULL pointer) for each integer in the range. I proposed this
before IIRC.
I think that in a case like this, you will always be able to map the
'important points' to integers.
9:39 a.m.
[Steve Harris]
On Mon, Mar 08, 2004 at 05:51:28 +0100, Tim Goetze
wrote:
it's still a wart. if you shun the work of changing swh-plugins, i'll
happily offer to patch it to remove the unit references.
in addition, with the patch you'll receive a separate file, format of
your choice, containing those removed unit names, ordered by plugin
and port, for free! :)
vriendelijk,
tim
and to repeat: if you don't want units to
appear in the plugin
sources, why are you satisified with "Frequency (Hz)"?
I'm only satisfied with it because its allready widely used, in in
practice its bascily OK. Not ideal, but OK. Even I have to be pragmatic
sometimes :)
10:07 a.m.
On Tue, Mar 09, 2004 at 02:28:41 +0100, Tim Goetze wrote:
[Steve Harris]
The work is not a problem (its a disposable perl script and some tidying),
it just changes something in LADSPA that probably should not be changed.
It might even require new IDs for all the plugins that get new port names.
(though I've changed ports in the past without changing IDs, bad Steve, no
bisciut).
I'm not sure that a slightly easier to read and slightly more efficient
text dipslay format is a worthwhile goal.
- Steve
On Mon, Mar 08, 2004 at 05:51:28 +0100, Tim Goetze
wrote:
it's still a wart. if you shun the work of changing swh-plugins, i'll
happily offer to patch it to remove the unit references. and to repeat: if you don't want units to
appear in the plugin
sources, why are you satisified with "Frequency (Hz)"?
I'm only satisfied with it because its allready widely used, in in
practice its bascily OK. Not ideal, but OK. Even I have to be pragmatic
sometimes :)
10:45 a.m.
[Steve Harris]
here, have one from my cookiejar. the spec doesn't require port names
to stay consistent throughout successor versions of a plugin. though i
agree it is nice if they do.
it's still
a wart. if you shun the work of changing swh-plugins, i'll
happily offer to patch it to remove the unit references.
The work is not a problem (its a disposable perl script and some tidying),
it just changes something in LADSPA that probably should not be changed.
It might even require new IDs for all the plugins that get new port names.
(though I've changed ports in the past without changing IDs, bad Steve, no
bisciut). I'm not sure that a slightly easier to read and
slightly more efficient
text dipslay format is a worthwhile goal.
i am, as you will have noticed. :)
amicalement,
tim
8 Mar
8 Mar
4:50 a.m.
On mån, 2004-03-08 at 01:39, Tim Goetze wrote:
attached you'll please find three files:
* a patch moving ladspa.h 1.1 to 2.0
* a program showing how a host evaluates 2.0 extensions
* a thoroughly documented example plugin making use of the extensions
OK!
How then is midi handled? Suppose your sample distortion could have one
its parameters set from a sequencer by, say modulation wheel?
/jens
changes to the patch with respect to the last version include
consolidation of the extended port info into a dedicated structure.
also included is a warning note concerning the deprecation of the
1.1 default value hints and some minor clarifications.
the patch defines HINT_MOMENTARY as asked by Taybin and Steve. it
also credits Taybin now (Steve already being credited).
-
the example plugin is written with the intention to show, in all its
sometimes gory detail, how ladspa works 'from the plugin side'. the
plugin is fully operational in hosts implementing either version of
the standard. (it doesn't even sound so bad at all :)
there are a number of more elegant ways to accomplish what the plugin
source does, but these have all been ignored for the sake of showing
exactly how things are coming together in ladspa.
-
if you expect the extension to make a plugin author's life harder by a
significant amount, i would like to ask you to go over the source code
of the example plugin and see for yourself.
all the places where the plugin refers to the 2.0 incarnation have
been marked as such. i'm confident you'll agree that words like
'invasive', 'incomprehensible', 'bloated' or
'complicating' are not
doing the extension justice.
i would also like you to consider that it is up to you, either plugin
or host author, to altogether ignore the extension and still come up
with something perfectly useful. you can always extend your work to
make use of the extension at a later date. all this takes is added
code, with no changes to what you already have.
-
my apologies offered for the obnoxious use of the '2.0' version tag
for this proposal. for sheer lack of fantasy, typing laziness and a
number of other bad habits, i couldn't come up with something better.
amicalement,
tim
ps: it is hoped that the example plugin source will be helpful to
aspiring plugin authors, no matter the fate of the extension proposal.
5:05 a.m.
On Mon, Mar 08, 2004 at 09:46:26AM +0100, Jens M Andreasen wrote:
On mån, 2004-03-08 at 01:39, Tim Goetze wrote:
In LADSPA the host handles MIDI mapping.
- Steve
attached you'll please find three files:
* a patch moving ladspa.h 1.1 to 2.0
* a program showing how a host evaluates 2.0 extensions
* a thoroughly documented example plugin making use of the extensions
OK!
How then is midi handled? Suppose your sample distortion could have one
its parameters set from a sequencer by, say modulation wheel?
10 Mar
10 Mar
2:53 a.m.
On mån, 2004-03-08 at 10:00, Steve Harris wrote:
In LADSPA the host handles MIDI mapping.
Would it be OK if my plugin listened to a named pipe instead of the
default /dev/midi? If so, then a sequencer could write a midistream to
the pipe just like any other midi device, and the problem ceases to
exist.
/jens
4:14 a.m.
On Wed, Mar 10, 2004 at 07:49:29 +0100, Jens M Andreasen wrote:
On mån, 2004-03-08 at 10:00, Steve Harris wrote:
But it causes a lot more. You need some way to guarantee that the timing
is consistent between plugins and host to make sure that automation
effects are deterministic.
In practice, having the host do the MIDI binding is good, it means you get
a consistent interface across all plugins and makes things a lot simpler.
If your host of choice doesnt support MIDI mapping then petition the
author :)
- Steve
In LADSPA the host handles MIDI mapping.
Would it be OK if my plugin listened to a named pipe instead of the
default /dev/midi? If so, then a sequencer could write a midistream to
the pipe just like any other midi device, and the problem ceases to
exist.
4:40 a.m.
On ons, 2004-03-10 at 09:08, Steve Harris wrote:
On Wed, Mar 10, 2004 at 07:49:29 +0100, Jens M
Andreasen wrote:
Well, the documentation only mentions "a small amount of time". If the
host thinks that 1024 samples at 44.1 is "a small amount", then whatever
happened in the midistream won't take effect before the next request for
samples. I think it is not my problem?
On mån, 2004-03-08 at 10:00, Steve Harris wrote:
But it causes a lot more. You need some way to guarantee that the timing
is consistent between plugins and host to make sure that automation
effects are deterministic.
In LADSPA the host handles MIDI mapping.
Would it be OK if my plugin listened to a named pipe instead of the
default /dev/midi? If so, then a sequencer could write a midistream to
the pipe just like any other midi device, and the problem ceases to
exist. In practice, having the host do the MIDI binding is
good, it means you get
a consistent interface across all plugins and makes things a lot simpler.
If your host of choice doesnt support MIDI mapping then petition the
author :)
- Steve
Uhmm .. So where do I find the midistream?
/jens
7:46 a.m.
On Wednesday 10 March 2004 12.05, Steve Harris wrote:
On Wed, Mar 10, 2004 at 09:36:42 +0100, Jens M
Andreasen wrote:
If it's a softsynth you are making I think Jack would be the way to go. Then
the synth could be a regular alsa-sequencer client.
/Robert
Uhmm .. So where do I find the midistream?
You dont, LADSPA doesnt do MIDI.
7359
days inactive
7362
days old
linux-audio-dev@lists.linuxaudio.org
38 comments
9 participants
participants (9)
-
Alfons Adriaensen -
Fons Adriaensen -
Jens M Andreasen -
Jesse Chappell -
Paul Davis -
Robert Jonsson -
Steve Harris -
Tim Goetze -
Tom Szilagyi