Hi James,
It has been a while since I've looked at this so I have to dig a bit
here. I don't think much has changed in the mean time though, except for
adding positioning and directional parameters.
James Sleeman wrote:
Erik I think you wrote the xmlsound.README file. Do you know if there
John Denker wrote:
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.
James Sleeman wrote:
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
On 01/23/2009 01:40 AM, Erik Hofman wrote:
Don't believe everything you read in the docs.
You'd better do, this is the specification of OpenAL.
I was talking about what happens in the Real World.
The specification of OpenAL does not supersede the laws
of physics.
There are lots of places
John Denker wrote:
On 01/23/2009 01:40 AM, Erik Hofman wrote:
Don't believe everything you read in the docs.
You'd better do, this is the specification of OpenAL.
I was talking about what happens in the Real World.
The specification of OpenAL does not supersede the laws
of physics.
James Sleeman wrote:
What would help though, is if there is some way to reload the sound.xml
Answering my own question for posterity:
|fgcommand(reinit, props.Node.new({ subsystem: fx }))
|
|from the wiki
http://wiki.flightgear.org/index.php/Howto:_Reload_sound_config_without_restarting_FG
|
* James Sleeman -- Friday 23 January 2009:
fgcommand(reinit, props.Node.new({ subsystem: fx }))
Also note that you can execute code in nasal-console tabs
by typing :digit, without having to open the dialog.
(There's no such shortcut for tab 10. Maybe I should have
numbered them starting with 0?)
Melchior FRANZ wrote:
So, if you put that code in tab 9, just type :9. Of course,
you can assign the code to a regular key binding as well.
Yeah.. I'm lazy, I wrote a function to do it automatically on
modification to the xml file. Added it to the wiki in case it's useful
for somebody
Erik Hofman wrote:
Alright, but I had the impression James was talking about the
implementation and not the reality.
I was :-)
Erik I think you wrote the xmlsound.README file. Do you know if there
is some other documentation I could look at, that might make it a bit
clearer as I think
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
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
* 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
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
* 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
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
* 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
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
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
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
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
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
21 matches
Mail list logo