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: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Mon May 13 2002 - 17:08:02 EEST


On Sun, May 12, 2002 at 02:41:07 -0400, Likai Liu wrote:
> 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

The normal solution to this problem is to use parameter edge filtering, ie.
a low-order lowpass filter on the parameter data.

> 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.

Yes, but its better that the plugins do it for themselves. The windowing
requirements of my two pitch scalers, mbeq and convolver (which are all
FFT based, are all pretty different, and it would be very hard to express
the differences to the host. The convolver is rectangular, the eq is
raised-cos and the scalers are Blackman-Harris. With varying overlap as
appripriate for the cpu cost.
 
> 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.

This, I think is useful, but its too complex for LADSPA. I think there is a
need for a more complex plugin format, preferebly back compatible with
LADSPA. Its not neccesary to explicity store tuple arrays though, N
array ports of the same length would be fine.

I nominate array port types, defaults, port units, proper metadata, a gui
standard and timestamped events for inclusion. ;)

- Steve


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

This archive was generated by hypermail 2b28 : Mon May 13 2002 - 17:01:37 EEST