Re: [linux-audio-dev] LADSPA Specs ?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA Specs ?
From: Likai Liu (news_AT_likai.net)
Date: Sun May 12 2002 - 21:41:07 EEST


I certainly agree that envelope control can be implemented by the host
passing dynamically changing parameters to the plugin. I have already
given a lot of thought on that. Consider the situation of a volume
adjustment plugin with host-controlled parameter as the envelope.
Suppose each buffer size is 128 samples, which is reasonably small for
dynamic parameter. When we want to do a fade-out, the host sends the
buffer to the volume adjustment plugin, specifying a decreasing,
negative gain each time. The problem is, for every 128 samples, there is
a leap of the control parameter, resulting in audiable steps of the
volume. Depending on the amount of parameter changes, this can be quite
audiable as clicks, even more so than how linear interpolation compares
to cubic resampling method. As Steve Harris pointed out, linear
interpolation does not have acceptable quality. I think it's even
pointless trying to convince him to accept the clicks caused by stepped
host-controlled dynamic parameters. Using arrays is one of the
extensible solutions on top of ladspa.

Another way to workaround this is to add a plugin property to tell the
host that cross-windowed processing is preferred. Say we have 1024
samples to process in 128 windows chunk of 64 samples overlap. First
time the host sends samples 0 - 127. Second time the host sends samples
64-191. Third time the host sends samples 128-255, and so on. For every
resulting buffer, the host crossfades between the cross-windowed part.
This property is actually necessary for plugins that do fft processing.

I appreciate when Paul Davis points out that a compressor/limitor
needing an n-point curve is clearly why I need the array extension. A
multi-band equalizer with non-fixed bands is also a very good example.
However, I don't intend to solve the GUI automation issue. For a generic
representation of an array, one can use a 2D cartesian coordinate plot.
The envelope array can be displayed, from 0% to 100% of time as the
X-axis (index), and the data is displayed as the value of Y = f(x). The
array pairs can be displayed more generally as a table of two columns,
even though it can perfectly be displayed as a 2D plot as well. I would
like to point out that, since array is a flexible (or ambiguous) data
structure, it largely requires the "hints" to make sense of it. That's
why I devise here specific ways to represent specific kinds of arrays in
the GUI.

If an existing host doesn't want to support the array port extension, it
can simply disable those plugins that require the passing of array
ports. Of course supporting this new feature will require the hosts to
make some changes. Again, this is just a proposal, and I'm not even
going to try to push people to use it.

Likai Liu


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun May 12 2002 - 21:35:27 EEST