Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Erik Hofman wrote: Julian Foad wrote: No. I am only suggesting changing the default value for the pitch offset, not the way it is used to calculate pitch which is and would still be ... Hmm, okay. If you are sure it works, then I see no objections. It may require a few changes in the exsisting sound configuration files and the documentation shouldprobably be updated to reflect this change. I will first make sure that each pitch in the configuration files has an explicit offset, so that they do not rely on the default. In fact, there is only one without an offset, and it is the A4's whine sound. Did the author realise that the default offset was 1.0? The 747's whine has an offset of 0.1 specified. Does the A4's whine sound right as RPM varies? I suspect that an offset of 0, or close to 0, would be better. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Julian Foad wrote: No. I am only suggesting changing the default value for the pitch offset, not the way it is used to calculate pitch which is and would still be pitch = (property * factor) + offset Therefore with my proposed change your first example would have to be changed to pitch property/engines/engine/rpm/property factor0.0012/factor offset1.0/offset /pitch Hmm, okay. If you are sure it works, then I see no objections. It may require a few changes in the exsisting sound configuration files and the documentation shouldprobably be updated to reflect this change. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
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: - 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. - 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. 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. 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. - 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. 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. - 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. By taking just one transformation I don't see that possibillity. 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
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Andy Ross wrote: If you guys are thinking of changing the way we do linear function of a property value definitions in configurations, let me argue for a slightly different way to do it: The problem with specifying a multiplier (e.g. scaling or rotation) and an offset is that these two opperations don't commute. Especially when coupled with a syntax that is order-independant (you can *specify* the scaling last, but it still happens first, or vice versa) it's a constant confusion for the user as to what the final result will be, with the end result that the generated configurations are hacked up balls of goo. Be honest everyone: how many people have ended up typing random values into things like this trying to get the results they expect? I know I have. Instead, why not specify a range mapping. That is, input values in the range [a,b] get mapped linearly to output values in the range [c,d]. Input values outside of [a,b] can be clamped to that range before computation. This has a few advantages: This doesn't sound like a bad idea at all. It is something which isn't used very common (at least not that I am aware of) but there are several situations where common behaviour doesn't make sence :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
[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 factor0.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 factor1.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 factor1000/factor min0.0/min max1.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
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
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
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
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
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Julian Foad wrote: Hey, it's slightly different! How about we scrap the differences and the anomalies and combine them? To do so, I'd suggest: If you guys are thinking of changing the way we do linear function of a property value definitions in configurations, let me argue for a slightly different way to do it: The problem with specifying a multiplier (e.g. scaling or rotation) and an offset is that these two opperations don't commute. Especially when coupled with a syntax that is order-independant (you can *specify* the scaling last, but it still happens first, or vice versa) it's a constant confusion for the user as to what the final result will be, with the end result that the generated configurations are hacked up balls of goo. Be honest everyone: how many people have ended up typing random values into things like this trying to get the results they expect? I know I have. Instead, why not specify a range mapping. That is, input values in the range [a,b] get mapped linearly to output values in the range [c,d]. Input values outside of [a,b] can be clamped to that range before computation. This has a few advantages: + Out of bounds values are eliminated by the clamping step. This is especially useful for sounds, where beyond-maximum scaling factors cause distortion. + The offset and multiplier are specified simultaneously and implicitly, so the user doesn't need to remember any precedence rules. + No need to handle the mind-bending gymnastics involved in negative scaling factors if you want something to scale in the reverse direction. (Negative scaling factors invert the direction of the offset only if the offset comes last; no wait... you get the idea). This is the way that YASim handles its property input and output specifiers*, and it's worked pretty well. Take a look at the reaction jet definitions for the harrier for an example of how much complexity this can eliminate. Andy * albeit not in a standard way -- YASim doesn't use the property tree parser, since I didn't know about it. It uses the lower-level XML callback API. -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
