Julian Foad wrote:
<...>
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.
It's not. It is a hack because the behaviour of the part is totally
different from the rest. By this "hack" you would be able to start at
the offset level and then scale down according to the property value and
the factor. That's why 2. isn't correct either ...
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.
The internal special values are releated to the current instance of the
sound. I figure it would be pretty hard to turn them into 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.
It's not a bug. A value with a pitch of 0.0 would have a frequency of
0.0 which isn't allowed and can't be heard. It actually should be 1.0!
- Decide whether multiple transformation groups are needed, and if so,
how they should be combined. I feel that, if more flexibility is
They are needed to add an envelope to the sound. It is for example
possible to start playing a sound based on a property, and change it's
behaviour based on another property (change it's pitch and/or volume).
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.
I'm not sure I understand what you mean by "I would like to be able to
use property values for the things that currently have to be constants",
but the idea of creating a general expression evaluator seems good enough.
May I send a patch to fix sound anomalies 1 and 3, anyway? (I always
like doing the little easy bits first.)
Neh, better not.
Erik
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
