[Flightgear-devel] Sound vol/pitch transforms are like panel x/y/r transforms

[Julian Foad]

Fg_sound.cxx implements a way to control the volume and pitch of a sound specified in an XML config file. The optional steps in the "volume" control group are (and the "pitch" group is the same):

- A variable value: one of
A named property
An internal special value (e.g. time since the sound started)

- Transformed by a function: one of
Inverse
Absolute
Square root
Logarithm

- Scaled by a (constant) factor

- Clamped to (constant) max and min

- Added to a (constant) offset

These all have sensible (no-change) defaults (except for anomaly 1 below). This group can be repeated; the results are multiplied together except for the offsets which are all added afterwards.

Anomalies:
1. The pitch offset defaults to 1, but I think that is just a bug.

2. Since the offsets are constant, it is redundant to specify more than one. This arrangement is therefore not ideal, but I'm not sure what would be best.

3. A negative scaling factor is only useful in the first group. This appears to be an unnecessary restriction. (The comment says "Hack!") The restriction can easily be removed and the code will be simpler for it.



The instrument panel transformations (x-offset, y-offset, rotation) have these optional steps:

- A variable value:
A named property

- Transformed by:
An interpolation table

- Clamped to (constant) max and min

- Scaled by a (constant) factor

- Added to a (constant) offset

These all have sensible (no-change) defaults. This group cannot be repeated.



Hey, it's slightly different! How about we scrap the differences and the anomalies and combine them? To do so, I'd suggest:

- Leave the handling of the internal special values in the sound module, or find a way to present them as properties.

- Add the Interpolate option to the list of functions (Inverse etc.).

- Swap the order of Scaling and Clamping in (probably) the sound module (because there are fewer uses there).

- Lose the pitch offset bug and the negative scaling factor hack.

- Decide whether multiple transformation groups are needed, and if so, how they should be combined. I feel that, if more flexibility is needed, a general expression evaluator would be better than providing one specific way to combine sub-expressions. For example, I would like to be able to use property values for the things that currently have to be constants.



May I send a patch to fix sound anomalies 1 and 3, anyway? (I always like doing the little easy bits first.)


- Julian


_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel