Re: to infinity and beyond (Re: ArtsCompressor state)

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Thu, Sep 16, 2004 at 03:34:57PM +0200, Tim Janik wrote:
> On Wed, 15 Sep 2004, Stefan Westerfeld wrote:
> > On Tue, Sep 07, 2004 at 11:02:11PM +0200, Tim Janik wrote:
> > > On Tue, 7 Sep 2004, Stefan Westerfeld wrote:
> > > > 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.
> > >
> > > i'm not sure what "infinity" is here. suppose you have a scale ranging
> > > from +12 to -96 (dB), do you:
> > >
> > > a) want the GUI to only do s/-96/-oo/ ?
> > >    (this could easily be done with a property hint)
> > >
> > > b) want the GUI to provide a normal slider intervall [+12,-96[ but at
> > >    position -96 display -oo and pass -G_MAXDOUBLE to the module?
> > >    (this would better be done by (a) and implementing the
> > >    -96 => -oo substitution in the module)
> > >
> > > c) want the GUI to do a *real* interpolation to oo? say we subtitute
> > >    "only" 1000 for oo: we still get major oscillations.
> > >    [...]
> > >
> > > as a consequence, beast currently supplies a usable scale down to a comparatively
> > > small dB value (most dB scales out there don't actually scale down to -96), but
> > > doesn't cheat by simply displaying "-96" as "-oo".
> >
> > In the cases I know, it is in fact not so important to get an
> > interpolation to infinity (its hard to define what that means, anyway).
> >
> > Its just that I would like to implement for instance in the compressor
> > that you can use the boundary case of oo:1 compression, which basically
> > means that the compressor is just acting as a limiter.
> >
> > For the user, it would be nice to _know_ that actually limiting is
> > taking place, so I'd like to have a slider like this:
> >
> >  ____________________________________________
> > |        |        |            |             |
> > 1:1     2:1      4:1          8:1           oo:1
> >
> > >From the implementation point of view, it is okay if 19.99 is right next
> > to infinity (or similar). And its also okay if I have to special case
> > this one value of the ratio_to_one property (20) in the module to mean
> > something else than ratio_to_one normally means.
> 
> if you have to change module behaviour in that particular case, then
> instead of special casing arbitrary scale values, why don't you simply
> add a toggle property that:
> 1) disables ratio editing while the toggle is active
> 2) triggers the specific compression behaviour you mean to implement
> 3) says something like: "Limiting Mode", "Enable limiting mode of the
>    compressor which works with infinite:1 compression ratio"

- because it is non-standard to have an extra property (see for instance
  http://www.behringer.com/02_products/proddetail.cfm?id=MDX2200&type=220&lang=ger
  for a photo of a compressor which has infinity on its knob; and they
  do have push buttons for other things, so there is no point in
  argueing that since its an analog device, extra push buttons don't
  work)

- because it wastes screen-space: this one might not be obvious in the
  case where you have a whole dialog, but if you have a RACK view or
  something embedded in a mixer, I think this might be an argument

- it is also non-trivial to automate it (but okay, I don't know whether
  it is too important for the user really to automate between finite and
  infinite compression ratio) via midi events (*)

- because the old compressor (where you specified the ratio as quotient)
  didn't need an extra property, and I think it felt nice there, that
  you could adjust the slope of the compression between 0 and 1 
  
  think of what I want to achieve as: just want to preserve this - very
  logic - user experience while changing
   (a) the direction of the slider (where left now means less
       compression and right more compression)
   (b) the labels of the slider (to say not 1 .. 0, but 1:1, 2:1, 4:1,
       8:1 and inf:1)
   (c) the scaling of the slider, to make it easier to edit the
       interesting part (which is between 1:1 and 8:1)

Maybe if you don't feel there should be special casing, maybe it is
worth to implement a special "ratio" scaler, which does the three things
I want to have, while supplying the module with the old quotient between
0 and 1?

The same could be used for dB properties where inf might be useful: the
module takes a percent property (or 0..1), and the slider says dB
nevertheless, with appropriate scaling. That way, you can pass -inf
easily (as 0).  +inf doesn't make sense in dB properties anyway.

(*) An interesting point about automation is this: we do have these
splined widgets, which allow us to make the interesting part more
adjustable at the GUI, by mapping pixel ranges non-linearily onto
resulting values in the module. Since, however, this improves the user
experience for a GUI, I see no reason why - for a real world user
interface, such as a midi slider on a keyboard which is bound to that
very property via automation - we shouldn't do the very same mapping.

That is: if the compressor has 70% of its screen space for the ratios
between 1:1 and 8:1 and 30% for the remaining ratios, then probably a
hardware knob should also have the same 70% 30% seperation; since if it
"feels good" at the GUI to have it, then it will also "feel good" in
hardware.

Of course, if you say that you don't want to implement the necessary
code, I can try to work around the issue, by either not supporting inf:1
compression at all, or adding the extra property.

Or if you say: it won't be done anytime soon, but maybe later, then it
is probably the best not to change what the compressor does right now
(since in practice, 20:1 compression is "fairly similar" to inf:1
compression), and add support for inf:1 once the GUI can do it.

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