Erik Hofman wrote:
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 ...
Not totally different. Quite similar. Have you looked at the code? The way I read it, a negative value causes the (scaled, clamped, etc.) value to be subtracted from the offset rather than added to it. That is exactly the same as just using a negative scaling factor. The only differences are:
- For negative, you want the default offset to be 1;
- For positive, you might want the default offset to be 1 or 0 depending on what you are doing!
- When the subtraction is done it forgets any value generated by a previous "volume" group, which means it's only useful in the first group (e.g. the first volume transformation of potentially several volume transformations).

OK, I did not notice the need for offset=1 in subtractions. However, this should be the case for volume just the same as for pitch. You don't want the volume to be subtracted from zero either.


- 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!
Offset=0 doesn't necessarily mean pitch=0. For example I want pitch=(K * propeller_rpm). When RPM=0 I don't care if pitch=0; I know it doesn't make sense, but volume will be zero too. Maybe the internal sound player algorithm will have to limit the minimum pitch to something other than zero, but that shouldn't stop me from requesting it to be "as near as possible to zero".


- 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).
No, we could have that ability with one volume transformation and one pitch transformation per sound. (These are separate from the sound on/off property.) I'm asking whether we need more than one transformation of each type.


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.
OK, I agree it's not as simple as I first thought. I'll think more carefully.

- Julian



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

Reply via email to