Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms

[Erik Hofman]

[EMAIL PROTECTED] wrote:

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.

:-)

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.

But if you look at the following example:

<pitch>
<property>/engines/engine/rpm</property>
<factor>0.0012</factor>
</pitch>

You would have to change it to the following to achive the same with your proposed change

<pitch>
<property>/engines/engine/rpm</property>
<factor>1.0012</factor>
</pitch>

while doing exactly the same for <volume> would require it to be written like the first example!

- 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.

Well, you could uncomment the __fg_sqr() and __fg_pow3() functions and use them to achive what you want, or use the clamping for that:

<pitch>
<property>/engines/engine/rpm</property>
<factor>1000</factor>
<min>0.0</min>
<max>1.0</max>
</pitch>

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.

Personally I think it is very powerfull as it is, it just takes some creativity to take advantage of all the possibilities.

Erik



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