ArtsCompressor state (Re: Sample and Hold module)

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Sun, Sep 05, 2004 at 04:54:25PM +0200, Tim Janik wrote:
> On Sun, 5 Sep 2004, [iso-8859-5] ????? ????? wrote:
> 
> > I've created (hopefully not too ugly) icons for s&h, compressor and a
> > ladspa icon with the LAD logo (attached). By the way, are both
> > compressor modules (mono and stereo) required? I believe,
> > StereoCompressor is sufficient, just like the Summation module is
> > "stereo" but is ok for mono work.
> 
> hm, ask stefan about that, i'm not familliar with the innards.
> i'm not even sure the modules are finished yet, afaik there're
> still some property changes pending, maybe he also intended to merge
> the modules...
> stefan, what's the exact state with the compressor module(s)?

Well, its 100% compatible with the aRts original modules, as it stands
now, so from that point of view, it is perfect. Staying 100% compatible
would mean that we can't remove the mono variant (as it would be supplied
for backward compatibility, then), and not change the algorithm and/or
properties.

But I think currently, it has usability issues. Let's look at the
properties:

Attack [ms] and Release [ms] are fine.

Threshold:

While specifying the threshold as "number" corresponds to
what the implementation does (checking signal level as "number"), I
have never seen that in real-world compressor user interface. So
probably we should specify the threshold in dB.


Ratio:

Same here: usually, the GUI should be configurable between 1:1, 2:1,
4:1, ... oo:1 compression. While this can be done with the slider we
have, it still leaves the division task up to the user. So he needs to
know that a value of 0.33 is a 3:1 compression. This also has the
unfortunate side effect that "more compression" is on the left side in
the gui, whereas "less compression" is on the right side. This is not
intuitive.

There is no scale in beast currently which allows infinity on it,
currently, though. Maybe 100 or 20 is a good enough approximation for
infinity in practice.


Output:

If theshold would be given in dB, then probably the output amplification
also should be given in dB - thats what other compressors do. Maybe it
should also be renamed. Jamin for instance calls this property "Makeup
gain", and has the ability of computing the "makeup gain" automatically
to suit the settings of threshold and ratio.


Curve:

We don't have a curve displaying widget yet, but if we had, displaying a
compressor curve might be useful.


So all these changes should probably be made. However, then we come to
something else that might need to be changed: if we specify all these
values in dB, and plot a curve in input dB -> output dB, then probably
the user will expect the slope of the curve to be 1 before the
threshold, and 1/ratio after the theshold. And thats what other
compressors do, algorithmically.

However, the ArtsCompressor doesn't modify signals according to this
curve. It operates on the signal levels as numbers (and not as dB), and
like this, it doesn't have this charactersic, which probably it should
have. So basically, I think its not even a "real compressor", but a
"buggy compressor" right now.


So hum. What to fix? Basically, coming back to the start of the e-mail,
it depends on what "porting a module" from aRts should mean. There are
currently 68 modules in aRts which implement the Arts::SynthModule
interface, which is similar to what Bse::Effect is. Some of them need
an input signal of something like 400 to even produce a reasonable
result (for instance Arts::Synth_FREQUENCY), which you can't create in
BSE easily.

There are two principal reasons why one might want to port them 1:1.

 * to allow importing .arts files without altering their sound
 * to allow existing applications which use the aRts API to use the new
   implementations one day, without altering their behaviour

I think, both are not too important. So basically, maybe "porting"
should be simply: taking an aRts module, looking what can't be done with
existing Bse modules already, fixing everything that should be fixed,
adding all bells and whistles that one wants to have, and finally adding
it.


Then, its possible to fix all of the above issues, and make
Arts::Compressor something quite different from the original
Arts::Compressor and Arts::StereoCompressor modules.


Comments? Thoughts? Ideas?

    Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan space twc de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-