Re: ArtsCompressor state

[Tim Janik <timj gtk org>]

On Tue, 7 Sep 2004, Stefan Westerfeld wrote:

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

it'd be good to have some elaborate explanation there on "threshold".
for one, the threshold tooltip should be extended, and for another
the module should get a decent description giving an overview of
its overall behaviour. for an example, take a look at the Info
dialog (context menu on modules) of a BseAmplifier (or DCA).

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

what do you mean with "this also has the ... effect"? are you referring
to the current way the slider in ArtsCompressor is setup?

i don't quite see the problem you describe. why don't you simply use
a property from 0..SOME_MAXIMUM that lets the user define the numerator
part of the compression ratio?


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

Jamin compressor? reference, url, typo?


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

we need a proposal on this first, and this part can savely be delayed until
we have curve or graph properties. the otehr properties should be fixed
ASAP though, because their values are saved to BSE files already.


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

are you trying to say that ArtsCompressor does linear compression currently
and should do logarithmic compression instead?

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

while i agree on the importance you outline, i'd like to add that in
order to import arts files, extra import code will have to be written
(like for instance the MIDI importer we already have), and such an
entity could just as well "translate" an arts mesh into a BSE mesh
(e.g. by doing linear<->dB translations or substituting one arts module
by two BSE modules), you don't need identical modules for that.
so it'd probably be better to turn the arts module porting act into
a chance to improve on them and do necessary but incompatible reworks.


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

from all i know so far, Arts::StereoCompressor (which should be
Bse::Arts::StereoCompressor btw) with only its first input/output
connected, performs just as well as Arts::Compressor with its
single input/output connected (performance and signal wise).
so if that holds true, i'd vote for getting rid of Arts::Compressor.

>
>     Cu... Stefan

---
ciaoTJ