dataspace: gain implementation

There are some competing concerns that need to be considered in the design of the gain dataspace. This is particularly true with regards to clipping the range.

It might be that we need two different units, e.g. a db unit and _clippeddb unit. Or maybe a template parameterization with a constant for the lower bound. Or ???

Here is an excerpt from the most illustrative of several messages from @lossius on the jamoma-devel list:

Based on my extensive experience with using dataspaces with ramps it is absolutely critical that the dB dataspace unit is implemented with a lower threshold that gets mapped to 0.000 linear. In 0.5.7 it was a common scenario to do the following in cue scripts:
        /foo/audio/gain 0. linear
        /foo/audio/gain 0. db ramp 5000
When starting the ramp, the current value gets mapped to dB as -INF, and blows audio up in all of the patch. provided that there is some feedback mechanism further down in the patch (e.g. feedback delays or filters) I have to close and reopen the patch in order to continue working. Additionally Max (at least up through version 6) does not do proper testing for -INF sample values being output, and as a consequence I have been very close to blow up and destroy speakers at numerous occasions.

Many months ago I therefore changed the dB unit of the dataspace so that the dB range can not go below -144.49 dB (24 bit range). This lower limit need to be upped to the lower limit that we now settle for (-96 or -70 dB).

From a mathematical/engineering point of view I understand the wish to keep maths “clean”, but we have to keep in mind that the dataspace lib is first and foremost a service used as part of the node structure. As such user interaction design concerns trumps maths. Having implemented dataspace+ramp first for 0.5.7 and then again for 0.6 I am pretty confident that I have used this feature way more than anyone else involved with the development. Please trust me when I say that not having this range limit in Jamoma 0.5.7 is by far the ugliest bug left in Jamoma 0.5.7. When it explodes, you risk damages to ears and speakers. The design we are moving towards now is the same as in Live, and this is definitively something that Live has gotten right.

jamoma / jamoma2

dataspace: gain implementation #42