Erik Hofman wrote: > > Julian Foad wrote: > > > > Not totally different. Quite similar. Have you looked at the code? The > > I've written the code.
Oh! ... sorry. I'll be very careful then. > > 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! > > 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. ... > 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. > > 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. I think we have a bit of confusion over the meaning of "offset". I think you want the default *output value* for the pitch to be 1.0, and for volume to be 0.0, which is fine. But I would expect to get this by having default input values of 1.0 and 0.0 respectively, transformed by output = ((input * scaling) offset), where the default scaling would be 1.0 and the default offset 0.0. This would give the same result but would allow the <volume> and <pitch> groups to use exactly the same semantics, which makes them easier to learn, makes the source code more maintainable, etc. Note that volume and pitch are both perceived logarithmically by humans. This means that scaling is more useful than offsetting. > >>> - 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. > > 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. Unfortunately, you can't add them up; they are always multiplied together. This is useful sometimes but not always. I wanted the engine volume to be proportional to (RPM throttle) so that it would be immediately become loud when you opened the throttle when it was idling. But I can't do that. It can be useful to have more than one property controlling the volume, but only if you can combine them in the way you want. > By taking just one transformation I don't see that possibillity. That's right. When I said "we could have that ability with one ..." I was referring to your comment "start playing a sound based on a property, and change it's behaviour based on another property (change it's pitch and/or volume)." I certainly do not want to delete any feature that is currently being used. I am looking for ways to simplify the code and semantics while *keeping* all the useful features. - Julian _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
