Julian Foad wrote:
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
I've written the code.
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:Maybe you don't understand the meaning of this value, but the result is used as a scaling factor for the playback frequency. So an offset 0f 1.0 (and nothing else) will cause the sound to be played in the recording speed. An offset of 0.5 (and nothing else)) will cause the sound the be played half the speed.
- 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).
Well, it looks like *that* is a bug which needs to be fixed.
I've used 0.0 as an offset value for volume to prevent the sound screaming out of the speakers if one weren't carefull enough.
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.
Really, pitch offset should be 1.0 and volume offset should be 0.0.
You can always override the default offset, but defaults should have a sane value, and for pitch *sane* means 1.0. For volume *sane* means 0.0.- 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".
I don't get it. The way it is now the sound manager has a great flexibillity in that it can assigne differen scaling factors to different properties and add them up together to calculate the resulting scaling factor. By taking just one transformation I don't see that possibillity.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.- 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).
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.
:-) No problem. Erik _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
