5 Mar
2004
5 Mar
'04
10:03 a.m.
the attached patch proves that LADSPA can be extended without breaking
binary compatibility. i've compiled plugins against a patched ladspa.h
and run them in hosts compiled against ladspa.h version 1.1 without
experiencing any problems.
also attached is a short test program that demonstrates how the
extensions provided by the patch can be put to use.
to demonstrate various possibilities and their relative ease of use,
the patch implements the following extensions:
hints:
* connect_port (NULL) is ok hint
member extensions to the descriptor:
* Version (major, minor)
* Latency
* char ** PortUnits
* LADSPA_Data * DefaultValues
* LADSPA_PortValueEnum ** PortValueEnum
the PortValueEnum is a structure having a char * Label and LADSPA_Data
Value member associating a value with a label. this arrangement is
deemed to suit integer enumerations as well as arbitrary association
of values with a label.
while the patch follows the general style of the original ladspa
header, more sophistication would probably need to go into it for a
production version, especially into the comments describing the
extended version mechanism and members.
vriendelijk,
tim
5 Mar
5 Mar
10:46 a.m.
On Fri, Mar 05, 2004 at 03:52:54PM +0100, Tim Goetze wrote:
the attached patch proves that LADSPA can be extended
without breaking
binary compatibility. i've compiled plugins against a patched ladspa.h
and run them in hosts compiled against ladspa.h version 1.1 without
experiencing any problems.
I suggested already a solutions that seems to be a lot simpler and does
not require any new fields or types. Probably oour two proposals crossed
midway.
--
Fons
10:51 a.m.
New subject: +trigger, Re: [linux-audio-dev] ladspa.h.diff
the attached patch proves that LADSPA can be extended
without breaking
binary compatibility. i've compiled plugins against a patched ladspa.h
and run them in hosts compiled against ladspa.h version 1.1 without
experiencing any problems.
attached is the same patch extended to define a TRIGGER hint.
amicalement,
tim
11:40 a.m.
New subject: +trigger, Re: [linux-audio-dev] ladspa.h.diff
On Fri, Mar 05, 2004 at 04:40:55PM +0100, Tim Goetze wrote:
the attached patch proves that LADSPA can be extended
without breaking
binary compatibility. i've compiled plugins against a patched ladspa.h
and run them in hosts compiled against ladspa.h version 1.1 without
experiencing any problems.
Some questions.
1. Why should the use of new HINT bits be conditional on 'version 2' ?
Hosts just ignore HINT bits they do not know.
2. Given a port number, how does the host find the PortValEnum ?
--
Fons
12:03 p.m.
New subject: +trigger, Re: [linux-audio-dev] ladspa.h.diff
[Alfons Adriaensen]
1. Why should the use of new HINT bits be conditional
on 'version 2' ?
Hosts just ignore HINT bits they do not know.
yes, i wondered myself. you can simply drop the version 2 condition
(the use of the hint bit implies version 2 anyway). though it will
be nice to connotate features with version dependency so coders
will know when they leave backwards-compatible terrain.
2. Given a port number, how does the host find the
PortValEnum ?
it's in the test program posted with the first patch:
/* (d = LADSPA_Descriptor * for the plugin) */
for (i = 0; i < d->PortCount; ++i)
{
printf ("--------------------------------------------\n");
printf ("port: %s\n", d->PortNames[i]);
printf (" default: %.1f\n", d->DefaultValues[i]);
printf (" unit: %s\n", d->PortUnits[i]);
if (d->PortValueEnum)
{
e = d->PortValueEnum[i];
while (e && e->Label)
{
printf (" value: %.2f = %s\n", e->Value, e->Label);
++e;
}
}
}
i'm quite confident it's not too complicated a solution.
amicalement,
tim
1:19 p.m.
New subject: +trigger, Re: [linux-audio-dev] ladspa.h.diff
On Fri, 5 Mar 2004, Tim Goetze wrote:
>the attached patch proves that LADSPA can be
extended without breaking
>binary compatibility. i've compiled plugins against a patched ladspa.h
>and run them in hosts compiled against ladspa.h version 1.1 without
>experiencing any problems.
Hi,
I like this new LADSPA spec. very much, thanks to Tim Goetze for working
it out! However, i have one bit of concern:
/* This member indicates the delay, in 1 / (sample rate) time units,
the plugin imposes upon processed signals. */
const LADSPA_Data Latency;
Wouldn't this break the possibility of adequate operation of plugins that
have a latency value dependent on user settings (ie. not constant)?
Previously it was said that only a few plugins need this, and it's hard to
implement it in a host. I agree. But there *are* plugins (i have one) that
rely on the possibility of varying latency to keep the output synced, and
some (serious, sophisticated) hosts could still choose to implement the
varying compensation. If it is forced to have a constant value, these
plugins and hosts will have to face a compromise. If it is not specified
as constant (ie. it can be overridden by "latency" output, or some other
way on-the-fly) then the hosts that don't implement varying compensation
would work no worse than with this constant spec., but the possibility
to have "advanced" hosts and plugins that use it would still remain.
So, i would propose to leave this Latency specification in place (for the
95% of plugins/hosts that don't need anything more), but state that the
value written to the "latency" output (if that output is provided by the
plugin) overrides this value and that could be changed anytime. What do
you think? (This kind of usage of "latency" output has to be implemented
in hosts anyway, so it may not be needed to change anything in this LADSPA
spec -- maybe state in the comment that it can be overridden, that's all.)
Tom
3:22 p.m.
New subject: +trigger, Re: [linux-audio-dev] ladspa.h.diff
On Fri, Mar 05, 2004 at 07:14:41 +0100, Tom Szilagyi wrote:
I like this new LADSPA spec. very much, thanks to Tim
Goetze for working
it out! However, i have one bit of concern:
/* This member indicates the delay, in 1 / (sample rate) time units,
the plugin imposes upon processed signals. */
const LADSPA_Data Latency;
Wouldn't this break the possibility of adequate operation of plugins that
have a latency value dependent on user settings (ie. not constant)?
The problem with non-constant latency is that it requires the host to set
the parameters and call run() once before it will know the value.
Also the semantics of variable latency are very confused - as the value
can vary at any point furing the run() steps the host cant know how to
correctly interpolte between adjcent values. Its just much to hard to do
anythign useful with.
I also /really/ dont think it belongs in the struct - its not an essential
feature and few hosts will support it.
Either design your plugins to do internal lantecy correction and report
the total or live with uncorrected latency :)
- Steve
7363
days inactive
7363
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Alfons Adriaensen -
Steve Harris -
Tim Goetze -
Tom Szilagyi