Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
Arnt Karlsen wrote: ..no F-g way, they add a restriction beyond the GPL, toss out all Boeing models and replace them all with similar Airbus, Tupolev, Antonov, Shin-Meiwa, Harbin, Dornier, Short etc models. And do it LOUDLY. ;o) Not true in my opinion, the GPL can't explicitly allow things that are beyond software distribution. So if trademark law prohibits the use of the brand name then the GPL is in no place to grant it anyhow. Erik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
Jon S. Berndt wrote: Arnt, they are completely within their rights to add that stipulation. You can bet all of the other manufacturers will have the same stipulations. That said, the note/ section is just a reminder to anyone who wants to make a profit by selling a 'Boeing 747' simulator or something similar. There are no consequences for the end user or for the FlightGear community by this statement. It would be interesting to know what Boeing thinks when their brand name is listed in a long list of supported Aircraft from several manufacturers instead. Erik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG environment and atmosphere (was: X-15 issue identified)
On 01/13/2009 12:43 PM, Torsten Dreyer quoted flying.toaster as follows: The issue is that JSBSIM gets the external atmospheric model (/environment/params/control-fdm-atmosphere set to true in flightgear). I assume that imposes flight gear own atmosphere model to the FDM and THIS model is stuck after 10 ft Setting this value to false actually gets a more realistic atmosphere past 100kft. The question being what should be done in order to get the proper behavior and not breaking everything else in flight gear ? Should JSBSim be allowed to impose its internal atmosphere model or should the FG model be modified to model the proper values for density in the upper atmosphere ? Yes, that's the right question ... and fortunately a good answer is available. Code exists to give FG an accurate model of the atmosphere, valid all the way to 262,467 MSL, i.e. 80 kilometers, i.e. the top of the mesosphere. (The limit could be raised even higher if anybody really wanted to go there.) This code has existed for years. It doesn't break FG. In fact, even if we consider only the troposphere, it gets rid of some ugly bugs in the existing model. The existing environment model does some crazy things, especially if the temperature is not ISA-standard. For more on this, see http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-environment -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
On Thursday, 22. January 2009, Jon S. Berndt wrote: Since it appears as though JSBSim will use the product identifiers (e.g..Boeing 737) in a descriptive manner, and no profit will be derived from said usage, then we have no objection to inclusion of the product identifiers on the software. However, if a situation arises in which the aircraft models are to be sold for a profit, please contact us to discuss implementation of a Trademark License Agreement for the sale of consumer products. Looks like a siple case to me: no copyright law involved, just trademark law. This should not be any problem for GPL'ed distribution. A very good example for this whould be the well known Mozilla Firefox browser. No one would argue that the software is free as it's MPL/GPL dual licensed. But they do not allow modified versions to use their trademark and call it Firefox. That's why it's called Iceweasel on Debian. So Boeing is actually more permissive than the Mozilla Foundation as they allow the trademark to be used in any non-profit situation. If someone want's to sell FlightGear or such models, they have to ask Boeing for a trademark license agreement or simply remove the trademark's usage from the software (like Debian does). So the way to go seems to be just to add a notice, that the model uses Boeing's trademark with clearance for any non-profit distribution while for other uses, the trademark's usage has to be removed or Boeing contacted. Not an additional restriction of the software license, but of the trademark usage. Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
James Sleeman wrote Hi Maik, Maik Justus wrote: the effect you are discussing is not the Doppler effect, but just the Yes, I know it's not a function of the Doppler itself, but I was thinking more along the lines of the volume drop off, if it were better, might help the convincingness of the Doppler, if you see what I mean. volume as a function of the distance. Every aircraft has its own sound definition including the distance, where the volume is halved (reference-dist) and the distance where the volume is cutted off (max-dist). Hmm, interesting. It seems that a great many aircraft do not define these values at all. Is there a default definition for these somewhere, is one calculated by openal maybe in the absence of these specific settings? At the end of this message is a quick grep showing the aircraft which do not define reference-dist. Quite a list. Just to clarify on the reference-dist, is it that this value is a diminishing effect, that is for reference-dist of 1 after distance 1 the volume is half original, after distance 2 the volume is 1/4 original (half of a half), distance 3 it's an 1/8th (half of a quarter). Or is it simply that at that specific distance, and for infinity beyond until max-dist the volume is always half the original? snip ... In simgear\source\simgear\sound\xmlsound.cxx I see that default values for reference-dist and max-dist seem to be specifed. It seems possible that these default values are no longer honoured. I think they worked at one time. It is going to be extremely tedious and time consuming to explicitly apply specific values to _every_ sound in fg. I would think that the attenuation of sound in air is amenable to mathematical calculation. Surely we shouldn't be guessing at some arbitrary reference distance? Vivian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
Jon S. Berndt wrote: I hope you agree with me that Boeing was very reasonable. I do hope we can be equally reasonable and fair, and comply with the GPL at the same time. This will require some creativity and thought. I won't argue the fairness of their position, but it's simply not compatible with the GPL. Even if you interpret their statement as a simple request to not use their name in promoting FlightGear or JSBSim, that's the same thing as the no advertising clause that kept the BSD license from being compatible with the GPL for years. [As an aside, I think it would be proper to apply the same approach (licensing, disclaimers, or whatever) across the board to all aircraft models where the company still exists or where the IP is still clearly owned.] A key phrase in the above reply from Boeing is, if a situation arises in which the aircraft models are to be sold for a profit, please contact us. Here again is the use of the word, profit. There is also the concept that all of the models are freely available, so that if someone is selling a copy of FlightGear and models, it can be argued that they could not possibly be deriving profit from selling a collection of files that is already available freely, but are instead deriving a profit from selling convenience. Many people, including my employer, would argue the contrary point for GPL'ed software in general. People who make money consulting with FlightGear, let alone selling it in a product, couldn't agree with you either. Let's take an example of a use for the B314: an engineer is payed by a museum to set up a B314 simulator using FlightGear, and the software (with source) is available on DVD in the gift shop. This is obviously permitted by the GPL, but it is not permitted by Boeing *unless you negotiate an additional license with them*. Nevertheless, I am not a lawyer. I don't have much time to think about this right now, but I think there's some valuable input being supplied here (and offline). Is there a consensus forming? Doubtful. We can't say that all the models in the repository are covered by the GPL and have models in there that are not. This is a terrible trap for anyone wanting to use FlightGear in any professional setting. We should consider why we want FlightGear and its models to be under the GPL in the first place. I suggest that we do because it's a very well known license that nicely balances the contributors' desire to give something to the community and at the same time not have their work be unfairly exploited. For the aircraft models, there are 3 not-very-attractive choices: * Don't say the aircraft are GPL'ed. Models are under any random license; seller beware. Yuck. * Rip out the non-GPLed models. * Create GPL'ed and other aircraft repositories. Tim -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
On Thursday, 22. January 2009, Tim Moore wrote: We can't say that all the models in the repository are covered by the GPL and have models in there that are not. This is a terrible trap for anyone wanting to use FlightGear in any professional setting. Please do not confuse the software license with other things like trademark law. There will always be things like trademarks, patents, warranty or other local laws that may add further restrictions to what you can do with software regardless of the software's license or it's validity. There are tons of free software that may not distributed as freely, as it's license (mostly GPL) would allow. I mentioned Mozilla Firefox earlier. But there's also things like simple mp3 codecs. Doubtless free software, but not as easy to distribute because of patent law in some countries. A copyright license can and should only care about copyright. It cannot free you from checking your other laws that may prevent you from doing what you want. Maybe you are not even allowed to sell _any_ software. That's not even a contrieved example: a four-year-old is not allowed to do so because he cannot enter a valid contract (which a sell would be). Does that make the GPL invalid? Of course not. So your museum just has two choices: * contact Boeing and get a license not for the software, but for the trademark * remove the usage of the trademark from the software before selling it There's nothing we could do about this. Except of course to abstain from using the trademarks in the first place. But as we have permission to use them for the stuff we really care about, I see no strong enough reason to do so. I'd just be nice to people and remind them to check their trademark usage. Stefan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
* Tim Moore -- Thursday 22 January 2009: * Don't say the aircraft are GPL'ed. Models are under any random license; seller beware. Yuck. * Rip out the non-GPLed models. * Create GPL'ed and other aircraft repositories. Or, as has been suggested before, do actually remove all occurrences of the name Boeing and use a substitute: Bingo737 m. PS: Yes, it's intentionally ridiculous. That will teach them! ;-) -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
Or, as has been suggested before, do actually remove all occurrences of the name Boeing and use a substitute: Bingo737 m. Boing 314? :-) Actually, David Slocombe had a good suggestion earlier. I'll formulate a letter to the Software Freedom Law Center and ask them for guidance. Jon -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
Hello, James Sleeman schrieb am 22.01.2009 01:14: Hi Maik, ... Just to clarify on the reference-dist, is it that this value is a diminishing effect, that is for reference-dist of 1 after distance 1 the volume is half original, after distance 2 the volume is 1/4 original (half of a half), distance 3 it's an 1/8th (half of a quarter). yes, exactly. Maik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
Hi, Maik Justus schrieb am 22.01.2009 13:45: Hello, James Sleeman schrieb am 22.01.2009 01:14: Hi Maik, ... Just to clarify on the reference-dist, is it that this value is a diminishing effect, that is for reference-dist of 1 after distance 1 the volume is half original, after distance 2 the volume is 1/4 original (half of a half), distance 3 it's an 1/8th (half of a quarter). yes, exactly. not exactly, it's 1/8th at distance 4 (doubled distance result in half volume). Maik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
* Jon S. Berndt -- Thursday 22 January 2009: Bingo737 Boing 314? That wouldn't work. It's too similar, as probably any court will find. Actually, David Slocombe had a good suggestion earlier. I'll formulate a letter to the Software Freedom Law Center and ask them for guidance. The problem isn't even so much complying with laws in multiple countries, but avoiding to get sued. Unfortunately, these are entirely different things. If that center says we are right, and Boeing says we are not, then what?! Is anyone willing to spend the money/time/nerves for a lawsuit, even if we are confident to be on the right side? I think you made a tactical mistake by writing in your letter none of our aircraft models are sold. Not only because it's wrong, but also because this raised their expectations. They might have agreed with a distribution under the GPL otherwise. But then again, I would not proactively avoid the trademark Eurocopter or MBB in the bo105. It's plausible that I act in good faith. I model an Eurocopter Bo105, after all, which is perfectly legal. So calling it that, too, seems rather obvious. It's like making a photo of a bo105 and labeling it Eurocopter Bo105 and distributing that. IANAL m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
Hi Vivian, Vivian Meazza schrieb am 22.01.2009 11:17: I would think that the attenuation of sound in air is amenable to mathematical calculation. Yes it is. (at lest if your distance to the sound source is large compared to the size of the source). Surely we shouldn't be guessing at some arbitrary reference distance? The problem is, we don't know, which distance the author was thinking about, as he defined/recorded the sound. For in-cockpit sounds the distance from the sound source to the cockpit may be a good guess, for out-of cockpit sounds the typical viewing distance of the aircraft could be a good guess, too. Therefore we will have two different guesses for e.g. the engine sound (as long as there are no different sounds defined for cockpit and external view)... Vivian Maik -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
* Maik Justus -- Thursday 22 January 2009: Vivian Meazza schrieb am 22.01.2009 11:17: I would think that the attenuation of sound in air is amenable to mathematical calculation. Yes it is. But it depends on the frequency pattern, no? So we'd need to analyze the spectrum ... time to use libfftw3. :-) I don't see why adding these values to the sound config should be such a problem. Don't we specify animation parameters to the smallest detail? Why should sound be different? OTOH, I would support global default values max-dist and reference-dist in preferences.xml, which an aircraft could override. And finally, every sound definition can still define its own values like before. JFTR: The bo105 sets these values since a while. :-P m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
On Wed, 21 Jan 2009 20:26:02 -0600, Jon wrote in message 003901c97c38$c8d5fe10$5a81fa...@net: However, if a situation arises in which the aircraft models are to be sold for a profit, please contact us to discuss implementation of a Trademark License Agreement for the sale of consumer products. ..no F-g way, they add a restriction beyond the GPL, toss out all Boeing models and replace them all with similar Airbus, Tupolev, Antonov, Shin-Meiwa, Harbin, Dornier, Short etc models. And do it LOUDLY. ;o) Arnt, they are completely within their rights to add that stipulation. ..I totally agree, that's why I recommend tossing out all Boeing models, and replace them with historically relevant models such as the Gimli Glider. You can bet all of the other manufacturers will have the same stipulations. ..that's why I recommend doing it LOUDLY. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
On Thu, 22 Jan 2009 09:37:39 +0100, Erik wrote in message 49783053.7020...@ehofman.com: Arnt Karlsen wrote: ..no F-g way, they add a restriction beyond the GPL, toss out all Boeing models and replace them all with similar Airbus, Tupolev, Antonov, Shin-Meiwa, Harbin, Dornier, Short etc models. And do it LOUDLY. ;o) Not true in my opinion, the GPL can't explicitly allow things that are beyond software distribution. So if trademark law prohibits the use of the brand name then the GPL is in no place to grant it anyhow. ..agreed, and that goes a bit beyond what I meant to say, but you are right here, and I stand firm on doing it LOUDLY. :o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
On Thu, 22 Jan 2009 09:42:30 +0100, Erik wrote in message 49783176.9020...@ehofman.com: Jon S. Berndt wrote: Arnt, they are completely within their rights to add that stipulation. You can bet all of the other manufacturers will have the same stipulations. That said, the note/ section is just a reminder to anyone who wants to make a profit by selling a 'Boeing 747' simulator or something similar. There are no consequences for the end user or for the FlightGear community by this statement. It would be interesting to know what Boeing thinks when their brand name is listed in a long list of supported Aircraft from several manufacturers instead. ..I can see it: ;o) Boeing XXX: Not supported due to trademark law concerns colditz: Colditz Escape Glider ... Gimli Glider : Supported, historical fuel management event ..and if Airbus should get too Boeing: ;o) Hudson Glider : Supported, historical ditch event -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing and disclaimers for aircraft models
On Thu, 22 Jan 2009 12:43:22 +0100, Melchior wrote in message 200901221243.23...@rk-nord.at: * Jon S. Berndt -- Thursday 22 January 2009: Bingo737 Boing 314? That wouldn't work. It's too similar, as probably any court will find. Actually, David Slocombe had a good suggestion earlier. I'll formulate a letter to the Software Freedom Law Center and ask them for guidance. The problem isn't even so much complying with laws in multiple countries, but avoiding to get sued. Unfortunately, these are entirely different things. If that center says we are right, and Boeing says we are not, then what?! Is anyone willing to spend the money/time/nerves for a lawsuit, even if we are confident to be on the right side? I think you made a tactical mistake by writing in your letter none of our aircraft models are sold. Not only because it's wrong, but also because this raised their expectations. They might have agreed with a distribution under the GPL otherwise. But then again, I would not proactively avoid the trademark Eurocopter or MBB in the bo105. It's plausible that I act in good faith. I model an Eurocopter Bo105, after all, which is perfectly legal. So calling it that, too, seems rather obvious. It's like making a photo of a bo105 and labeling it Eurocopter Bo105 and distributing that. IANAL ..in proactive good faith, wouldn't the Bo105 have more or less, um, descriptive nicknames? ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
Melchior FRANZ Subject: Re: [Flightgear-devel] doppler volume * Maik Justus -- Thursday 22 January 2009: Vivian Meazza schrieb am 22.01.2009 11:17: I would think that the attenuation of sound in air is amenable to mathematical calculation. Yes it is. But it depends on the frequency pattern, no? So we'd need to analyze the spectrum ... time to use libfftw3. :-) Well even taking some arbitrary mid frequency would be better than a wild guess. I don't see why adding these values to the sound config should be such a problem. Don't we specify animation parameters to the smallest detail? Why should sound be different? And usually there are default values. OTOH, I would support global default values max-dist and reference-dist in preferences.xml, which an aircraft could override. And finally, every sound definition can still define its own values like before. I don't see any particular merit is setting the value in preferences.xml, but it would be nice if the default values worked as designed, no matter where they are set. JFTR: The bo105 sets these values since a while. :-P Well done, but what do you base the values on? Vivian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] flyby volume (was: Doppler volume)
On 01/22/2009 05:47 AM, Maik Justus wrote: Just to clarify on the reference-dist, is it that this value is a diminishing effect, that is for reference-dist of 1 after distance 1 the volume is half original, after distance 2 the volume is 1/4 original (half of a half), distance 3 it's an 1/8th (half of a quarter). yes, exactly. not exactly, it's 1/8th at distance 4 (doubled distance result in half volume). Sorry, no, it's not any of those. In the present situation, the levels go like this: r power power / r0/ (w/m^2) / dB 0.5 4.0 +6.0 0.7 2.04082 +3.1 1 1.0 0.0 reference 1.5 0.4 -3.5 2 0.25000 -6.0 3 0.1 -9.5 5 0.04000 -14.0 7 0.02041 -16.9 10 0.01000 -20.0 15 0.00444 -23.5 20 0.00250 -26.0 30 0.00111 -29.5 50 0.00040 -34.0 70 0.00020 -36.9 100 0.00010 -40.0 We see that at the reference distance (r0), the signal is not attenuated at all. That's the defining property of the reference point. At twice that distance, the signal is down by a factor of 4. At three times the distance, the signal is down by a factor of 9. It is the famous one over r squared law. It is a corollary of conservation of energy. *) At larger distances sound energy is not (by itself) conserved, i.e. dissipation becomes dominant, and we see a crossover to exponential attenuation, but ... *) At the distances we see in flyby view, dissipation is negligible. The 1/r^2 attenuation is the whole story. If you know the sound level at any one distance, you can calculate it at any other distance. On 01/21/2009 05:46 AM, James Sleeman wrote: ... if we switch to tower view, it seems you can always hear the aircraft no matter how far away you get, for example, I was 100 miles from the tower and yet I had no trouble hearing the aircraft at all. That's a bug. The tower cab has lots of sound insulation, so the tower guys are not going to hear the aircraft at all unless it is very close. If it's not close, 1/r^2 attenuation predicts that the sound level will be inaudibly low. And dissipation makes it even lower. On 01/21/2009 05:14 PM, James Sleeman wrote: It seems that a great many aircraft do not define these values at all. Is there a default definition for these somewhere, is one calculated by openal maybe in the absence of these specific settings? IMHO it would be a step in the wrong direction to ask aircraft designers to specify the reference distance. There's already a length-scale built into the flyby view, namely the expected distance of closest approach. There needs to be some headroom in the sound level, because the aircraft might maneuver so as to come closer than expected. On 01/22/2009 03:17 AM, Vivian Meazza wrote: I would think that the attenuation of sound in air is amenable to mathematical calculation. It is. In the near field it goes like 1/r^2. In the far field it is exponential; see FAR A36.7 if you want the lurid details, or see http://www.sfu.ca/sonic-studio/handbook/Sound_Propagation.html if you want something more explanatory. Surely we shouldn't be guessing at some arbitrary reference distance? There should be no guessing involved ... but there does need to be a reference of some kind. There needs to be something to set the scale. This is the premise of the statement above: _if you know the sound level at any one distance_ you can calculate it at any other point. On 01/22/2009 06:05 AM, Melchior FRANZ wrote: But it depends on the frequency pattern, no? So we'd need to analyze the spectrum ... time to use libfftw3. No, the 1/r^2 attenuation is independent of frequency. No FFT required. The long-range exponential dissipation would be another story, but we don't need to go there, not for the applications presently contemplated. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] doppler volume
* Vivian Meazza -- Thursday 22 January 2009: Melchior FRANZ I don't see any particular merit is setting the value in preferences.xml, but it would be nice if the default values worked as designed, no matter where they are set. It's always nice to have default values changeable, rather than hard-coded. So a property is the right choice. And preferences.xml is the place to initialize properties. And then, these values might have to be changed at runtime: Sound propagation also depends on the atmosphere, the terrain, etc. Probably nobody would ever bother, but having the possibility doesn't hurt either. JFTR: The bo105 sets these values since a while. :-P Well done, but what do you base the values on? Real life experience and guessing. That's not much worse than an unscientific calculation. If somebody doesn't like the values, just complain and I might change them. m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume (was: Doppler volume)
John Denker wrote Just to clarify on the reference-dist, is it that this value is a diminishing effect, that is for reference-dist of 1 after distance 1 the volume is half original, after distance 2 the volume is 1/4 original (half of a half), distance 3 it's an 1/8th (half of a quarter). yes, exactly. not exactly, it's 1/8th at distance 4 (doubled distance result in half volume). Sorry, no, it's not any of those. In the present situation, the levels go like this: r power power / r0/ (w/m^2) / dB 0.5 4.0 +6.0 0.7 2.04082 +3.1 1 1.0 0.0 reference 1.5 0.4 -3.5 2 0.25000 -6.0 3 0.1 -9.5 5 0.04000 -14.0 7 0.02041 -16.9 10 0.01000 -20.0 15 0.00444 -23.5 20 0.00250 -26.0 30 0.00111 -29.5 50 0.00040 -34.0 70 0.00020 -36.9 100 0.00010 -40.0 We see that at the reference distance (r0), the signal is not attenuated at all. That's the defining property of the reference point. At twice that distance, the signal is down by a factor of 4. At three times the distance, the signal is down by a factor of 9. It is the famous one over r squared law. It is a corollary of conservation of energy. *) At larger distances sound energy is not (by itself) conserved, i.e. dissipation becomes dominant, and we see a crossover to exponential attenuation, but ... *) At the distances we see in flyby view, dissipation is negligible. The 1/r^2 attenuation is the whole story. If you know the sound level at any one distance, you can calculate it at any other distance. On 01/21/2009 05:46 AM, James Sleeman wrote: ... if we switch to tower view, it seems you can always hear the aircraft no matter how far away you get, for example, I was 100 miles from the tower and yet I had no trouble hearing the aircraft at all. That's a bug. The tower cab has lots of sound insulation, so the tower guys are not going to hear the aircraft at all unless it is very close. If it's not close, 1/r^2 attenuation predicts that the sound level will be inaudibly low. And dissipation makes it even lower. On 01/21/2009 05:14 PM, James Sleeman wrote: It seems that a great many aircraft do not define these values at all. Is there a default definition for these somewhere, is one calculated by openal maybe in the absence of these specific settings? IMHO it would be a step in the wrong direction to ask aircraft designers to specify the reference distance. There's already a length-scale built into the flyby view, namely the expected distance of closest approach. There needs to be some headroom in the sound level, because the aircraft might maneuver so as to come closer than expected. On 01/22/2009 03:17 AM, Vivian Meazza wrote: I would think that the attenuation of sound in air is amenable to mathematical calculation. It is. In the near field it goes like 1/r^2. In the far field it is exponential; see FAR A36.7 if you want the lurid details, or see http://www.sfu.ca/sonic-studio/handbook/Sound_Propagation.html if you want something more explanatory. Surely we shouldn't be guessing at some arbitrary reference distance? There should be no guessing involved ... but there does need to be a reference of some kind. There needs to be something to set the scale. This is the premise of the statement above: _if you know the sound level at any one distance_ you can calculate it at any other point. On 01/22/2009 06:05 AM, Melchior FRANZ wrote: But it depends on the frequency pattern, no? So we'd need to analyze the spectrum ... time to use libfftw3. No, the 1/r^2 attenuation is independent of frequency. No FFT required. The long-range exponential dissipation would be another story, but we don't need to go there, not for the applications presently contemplated. Looks good to me. Thanks for the explanation. I suppose we don't allow for humidity and pressure? I get the impression that sound in the flyby view doesn't vary with height? I don't think aircraft designers should be asked to specify the reference distance either, but the ability to do so should remain - for in-cockpit sounds for example where the attenuation isn't standard. I'd even settle for a simple internal tag so that such sounds were not audible in external views. Actually, I thought we had one. Guess I must have dreamt that one up! Vivian -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___
Re: [Flightgear-devel] flyby volume (was: Doppler volume)
* John Denker -- Thursday 22 January 2009: On 01/22/2009 06:05 AM, Melchior FRANZ wrote: But it depends on the frequency pattern, no? So we'd need to analyze the spectrum ... time to use libfftw3. No, the 1/r^2 attenuation is independent of frequency. No FFT required. The law is the same, but the distances aren't. Lower frequency travels farther. I don't think that's irrelevant. An automatic calculation wouldn't know of which kind the sound is. m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume (was: Doppler volume)
On 01/22/2009 02:20 PM, Vivian Meazza wrote: Looks good to me. Thanks for the explanation. :-) I suppose we don't allow for humidity and pressure? In the 1/r^2 attenuation regime, none of that matters. Again, the exponential dissipation regime would be another story. I get the impression that sound in the flyby view doesn't vary with height? In some sense, height (Z) isn't any different from X or Y ... they all three contribute to the distance on an equal footing. For sure the biggest opportunity for improvement is to get the distance dependence right. 1/r^2 should suffice for present purposes. If the peak volume at nearest approach is not loud enough to break dishes, then the low volume will be inaudible before corrections to 1/r^2 become necessary. After that, for sure the biggest opportunity is _geometry_, in particular the _ground bounce_ that would reach the flyby observer. This would not produce a discernible echo but would cause constructive interference at some wavelengths and destructive interference at other wavelengths. There's even a good algorithm for modeling this, but I can't imagine it would be worth the trouble. There's a long list of more important things that need fixing. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume
* Vivian Meazza -- Thursday 22 January 2009: I don't think aircraft designers should be asked to specify the reference distance either, Sure, some automatism would be nice. I might even drop my hand-crafted values if that works well. It would be nice to have a modulation factor property that multiplies the distance calculations. Then one could change that depending on wind direction, atmosphere, terrain, ... m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Update to data/Aircraft/Instruments-3d/kx165
I believe that the correct behaviour is as follows: Decrementing 126.00 results in 126.97 Incrementing 126.97results in 126.00 Are you sure? I believe the curren behaviour is correct but not for sure ;-) I check it out within the next few days and drop a line here (probably not before the weekend). Hi Stuart I owe you a reply - sorry for keeping you on hold for so long. I have verified that the behaviour you described is correct: wrapping around the kHz does not change the MHz. I tested a KX165 and a KX155. Would you mind posting the intended patch for the kx165, so I can give it a try? Thanks, Torsten -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume (was: Doppler volume)
On jeudi 22 janvier 2009, Melchior FRANZ wrote: * John Denker -- Thursday 22 January 2009: On 01/22/2009 06:05 AM, Melchior FRANZ wrote: But it depends on the frequency pattern, no? So we'd need to analyze the spectrum ... time to use libfftw3. No, the 1/r^2 attenuation is independent of frequency. No FFT required. The law is the same, but the distances aren't. Lower frequency travels farther. Not fully right. Only right when high frequencies are stopped by objects. Low frequencies could go over, and farther The wider and the heavier the objects are, the lower the frequency may only go through. If there is no object between the emissive sound and the recever/listener the full auditive band ( 20/2 hz) is traveling to the same distance. I don't think that's irrelevant. An automatic calculation wouldn't know of which kind the sound is. m. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume
* gerard robin -- Thursday 22 January 2009: On jeudi 22 janvier 2009, Melchior FRANZ wrote: The law is the same, but the distances aren't. Lower frequency travels farther. Not fully right. Only right when high frequencies are stopped by objects. Yes, and there are enough particles in air to have that effect. That's the atmosphere. :-} m. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume
Hi John, great answer, thanks.. John Denker wrote: We see that at the reference distance (r0), the signal is not attenuated at all. That's the defining property of the reference So the reference distance is actually the distance from the microphone to the sound emitting device when the sample was captured? Here's what the docs (docs-mini/README.xmlsound) say, they don't quite seem to match that. Or has all this just wooshed over my head and I have to read your message again more carefully? reference-dist Set a reference distance of sound in meters. This is the distance where the gain/volume will be halved. This can be useful for limiting cockpit sounds to the cockpit. max-dist Set the maximum audible distance for the sound in meters. This can be useful for limiting cockpit sounds to the cockpit. IMHO it would be a step in the wrong direction to ask aircraft designers to specify the reference distance. There's already a length-scale But given that only the person who captured the sound sample knows the reference for real, isn't it at least ideal to specify that reference? Perhaps for our intents-and-purposes a reasonable guess could be made based on the sound type, that is, it might be reasonable to assume that if not specified the reference distance for an engine sound is probably around 10 meters in most cases. I can't imagine there would be a really big difference in saying the reference was 10 meters or 20 meters. For things like flap, gear and switches, the max-dist is probably more important than distance as these things are really internal sounds, max-dist of a meter or two would likely suffice. --- James Sleeman -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume
On 01/22/2009 04:20 PM, James Sleeman wrote: Hi John, great answer, thanks.. :-) We see that at the reference distance (r0), the signal is not attenuated at all. That's the defining property of the reference So the reference distance is actually the distance from the microphone to the sound emitting device when the sample was captured? Well, that would be true if your record and playback system and unity gain from end to end ... which is almost certainly not the case. There are too many places where it is possible (or even necessary) to mess with the volume knobs. There is a huge element of arbitrariness and artificiality in the whole exercise, because few gamers are going to turn up there computer audio systems loud enough to be faithful to the sound levels in a real airplane. All we can hope for in the cockpit is _balance_ i.e. a reasonable balance between the volume of engine noise, wind noise, gear motor noise, radio reception, et cetera. There is additional arbitrariness in the flyby view. Is the observer wearing ear projection? I hope so. What kind? I have no idea. Here's what the docs (docs-mini/README.xmlsound) say, they don't quite seem to match that. Or has all this just wooshed over my head and I have to read your message again more carefully? I stand by what I wrote. Don't believe everything you read in the docs. But given that only the person who captured the sound sample knows the reference for real, isn't it at least ideal to specify that reference? Again, fiddling with the gain is tantamount to fiddling with the reference distance. If you obtain a calibrated recording, with calibrated distances and calibrated sound pressure levels, then you can try to do something _ab initio_. But FG is a long long way from that level of precision. My recommendation: Fiddle the volume so that it sounds about right at the point of closest approach, and scale everything else by 1/r^2. That would be a huge improvement over the existing code ... and going beyond that would yield diminishing returns. Perhaps for our intents-and-purposes a reasonable guess could be made based on the sound type, that is, it might be reasonable to assume that if not specified the reference distance for an engine sound is probably around 10 meters in most cases. See previous recommendation. I can't imagine there would be a really big difference in saying the reference was 10 meters or 20 meters. Actually that is a 6dB difference. Maybe not really big but certainly quite noticeable. For things like flap, gear and switches, the max-dist is probably more important than distance as these things are really internal sounds, max-dist of a meter or two would likely suffice. None of this reference distance stuff has any applicability inside the cockpit. Engine noise _fills_ the cockpit. Moving your head around inside the cockpit does not make much difference, and to the extent that it makes any difference at all you would need a trmendously complicated model. A simple reference point model is dead on arrival. Similarly I assume you (the pilot) are wearing headphones, so moving your head around in the cockpit won't have any effect on ATIS or other radio traffic. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume
On jeudi 22 janvier 2009, Melchior FRANZ wrote: * gerard robin -- Thursday 22 January 2009: On jeudi 22 janvier 2009, Melchior FRANZ wrote: The law is the same, but the distances aren't. Lower frequency travels farther. Not fully right. Only right when high frequencies are stopped by objects. Yes, and there are enough particles in air to have that effect. That's the atmosphere. :-} m. Particles are a filter only for very high frequencies out of the audible range Atmosphere is the transmitter, without atmosphere there is no sound. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume
John Denker wrote: There is a huge element of arbitrariness and artificiality in the whole exercise, because few gamers are going to turn up there ... Again, fiddling with the gain is tantamount to fiddling with the reference distance ... None of this reference distance stuff has any applicability inside the cockpit. Engine noise _fills_ the cockpit. Moving your hea You are of course, right. The more I think about it, the more I see how really arbitrary and subjective it just has to be because of all the variables that we can't possibly accommodate, and it comes down to fiddling with essentially arbitrary numbers until it sounds good, if the end result is the same, it sounds good, what does it matter in the end (FlightGear is not an audio-sim, sound is just to enhance the immersion so at the end of the day, it's ear candy and what works, works, I think people would agree). I'm also thinking that (especially for engine noise) basing both the in-cockpit and outside of cockpit sounds on the same file (as most present aircraft will do), is perhaps not ideal in producing good sounds for both environments, there is just so much difference (especially if you bring headsets into the equation!) that all the number juggling, pitch and volume changing in the world is not going to really sound right for both environments, and that this is most pronounced in the flyby, were pitch and volume changes are most applied. I'm going to do some experimenting with trying different sound sample for inside and outside, or maybe even different sounds specifically for fly-by (and tower) views - totally non GPL and thus not-commitable because I'm just going to try ripping sound from youtube video(s) but I think it will still be a worthwhile experiment [of course, nothing to say I couldn't approach the publisher to see if they will GPL the sound for us if it worked I suppose]. What would help though, is if there is some way to reload the sound.xml file without actually restarting FG, so I could tweak numbers on-the-fly as it were, it's difficult to say adjusting this value makes it sound better when you are interrupted by restarting between times. Can somebody tell me if it's possible to do this? Ideally, FG would watch the xml file for modifications and reload it the second I change it. PS: My original question was regards volume changing to assist convincingness of doppler shifting, and I can confirm that, completely subjectively, when I set reference-dist and max-dist for the Hunter (with suitably guessed and adjusted values) I think it did help the doppler sound better, and made the tower silent when the aircraft was suitably distant (quiet but noticable from the tower with the aircraft at the threshold of 28R at SFO, as one would expect). --- James Sleeman -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flyby volume
Two pieces of physics that haven't heretofore been mentioned: 1) Propeller noise is fairly directional. For more on this, see http://www.google.com/search?q=propeller+noise+directivity This means that when a Real World aircraft flies past, you will hear a more rapid build-up and more rapid fall-off than could be explained by the basic 1/r^2 dependence. Note that the same physics sometimes produces no effect or even the opposite effect for helicopters, depending on whether the geometry is fly-by or fly-over. On the other hand, keep in mind that the propeller is not the only source of noise. There is also a lot of engine noise. Piston engine noise is not usually so directional. FWIW note that recent versions of the FG c182rg have separate models for engine noise and propeller noise, as you can easily observe by running at high RPM and then pulling the mixture. 2) In polar coordinates, the wave equation is _dispersive_, even though in rectangular coordinates it is non-dispersive. Spherical Bessel functions are different from plane waves. The dispersion changes the timbre of the sound. This is why people far away from an explosion think high explosives go boom even though up close they don't go boom at all; they go SNAP! If you were serious about modeling flyby sounds, you would need to account for this. In principle it might not even be hard; you could probably do a lot with an all-pass phase shifter with a movable tap. In practice, it's a mess. Digital filters benefit a lot from MMX instructions ... but then you run into portability problems. asoundlib has pitch bender functions built in (for Doppler) but last time I checked it didn't support arbitrary digital filters. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
