Re: [Flightgear-devel] FlightGear Sound System redux
James Turner wrote: > Excellent news. My biggest two requests would be to get the sound code > out of main.cxx, and proper support for positional sources - i.e AI or > MP traffic. Being able to position sounds on the airframe would be > good too - engine and gear noises especialy. Tom P wrote: > When switching to an external view like the tower, the same channel is > used for both, and the sound pitch is scaled to account for the Doppler > effect. > The effect is not realistic, you hear a high-pitch version of the > warning messages from a mile away. Both will be adressed. The problem Tom describes has something to do with improper doppler effect and a nasty way to fix it. I Think I've found why doppler didn't work properly in the first place. Erik -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
Hi John, John Denker wrote: > That's a good thing to work on. Thanks for the heads-up. > > Here's one more thing to think about in this context: > text to speech. AFAICT the status is: > 1) The existing home-brew TTS system (involving > ATC/default.vce and ATC/default.wav) is very limited. > It does not claim to handle the general case. It > does not even have enough vocabulary to handle an > ICAO standard ATIS (with perhaps verrry rare exeptions). > It only knows the names of a few airports. > 2) There is a documented interface to the Festival > TTS system. Alas, the preponderance of the evidence > indicates this has not worked in several years. > AFAICT all reports of working TTS refer to the > home-brew system (item 1 above). > > I have no opinion on _how_ to implement TTS, whether > home-brew, Festival, or other. For the sake of simplicity (or actually avoiding extra complexity) this will have to wait until after the update which shouldn't be a real problem since it only uses the sound infrastructure but is no part of it. Erik -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
Hi Durk, Durk Talsma wrote: > That sounds pretty awesome. (Sorry for the lame pun). :-) :) > Seriously, though, since you mention that this is something you're working on > for the longer term, do you think this planned update should be included in > the new release (planned beta release around FSWeekend), or do you want to > schedule this for a later inclusion? > > I'm not by any means trying to push you, I'm just trying to get a bit of an > idea what new developments we might expect in the next few weeks/months. Much of it is moving code around but I can't predict if it may cause nasty bugs that have to be hunted down. I hope to get it finished as soon as possible though. If it gets delayed it might be a good idea to hold it off for inclusion after the event. Erik -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On 20 Sep 2009, at 08:18, Erik Hofman wrote: > Both will be adressed. The problem Tom describes has something to do > with improper doppler effect and a nasty way to fix it. I Think I've > found why doppler didn't work properly in the first place. That's fantastic news! Let me know if I can help at all. One thing I thing I would strongly suggest on the FG side, would be to ensure the SG side uses Mathias' excellent basic types (SGVec3d/f, SGQuatd, etc) to express positions, vectors and orientations to the code. The SG layer itself could then manage converting to OpenAL co-ordinates and types (which are usually just ALfloat*, I know). My impression is that this would make *all* the client code much smaller, simpler, and less prone to 'which co-ordinate system am I in?' confusion. Regards, James -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
James Turner wrote: > Let me know if I can help at all. One thing I thing I would strongly > suggest on the FG side, would be to ensure the SG side uses Mathias' > excellent basic types (SGVec3d/f, SGQuatd, etc) to express positions, > vectors and orientations to the code. The SG layer itself could then > manage converting to OpenAL co-ordinates and types (which are usually > just ALfloat*, I know). I might need some help to understand quads, but I am converting it to SGVec3f where ever possible. Erik -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On 20 Sep 2009, at 09:25, Erik Hofman wrote: > I might need some help to understand quads, but I am converting it to > SGVec3f where ever possible. No problem, I'm sure Mathias / Tim / myself can oblige. One other I've remember from looking at the code - for some reason we always positioned the listener at (0,0,0), and do a lot of work to transform world positions into a listener-relative basis. As I understand it, OpenAL can do that itself, i.e we could use a 'world' transform for most of the source positions (which would be simpler), and pass the FGViewer orientation as the OpenAL listener orientation. I *think* at that point the OpenAL and OSG local cartesian systems would be in-sync, which might help people generally understanding the code! I do recall some story, that there was a problem with giving the OpenAL listener a non-default position, but I've totally forgotten the origin of that story, whether it applied to a specific OpenAL version/ platform, or whatever. Or maybe I imagined it. Regards, James -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
James Turner wrote: > On 20 Sep 2009, at 09:25, Erik Hofman wrote: > >> I might need some help to understand quads, but I am converting it to >> SGVec3f where ever possible. > > No problem, I'm sure Mathias / Tim / myself can oblige. Thanks! > One other I've remember from looking at the code - for some reason we > always positioned the listener at (0,0,0), and do a lot of work to > transform world positions into a listener-relative basis. As I > understand it, OpenAL can do that itself, i.e we could use a 'world' > transform for most of the source positions (which would be simpler), > and pass the FGViewer orientation as the OpenAL listener orientation. > I *think* at that point the OpenAL and OSG local cartesian systems > would be in-sync, which might help people generally understanding the > code! True, and I expect it's also the reason why doppler didn't work correctly (besides that the listener velocity wasn't updated while OpenAL needs both the listener velocity and the source velocity for proper calculation of the doppler effect). What I'm planning on doing is let the SoundManager handle the OpenAL context suff /and/ the listener properties and let the individual SampleGroups handle positioning and handling the properties of all associated samples. > I do recall some story, that there was a problem with giving the > OpenAL listener a non-default position, but I've totally forgotten the > origin of that story, whether it applied to a specific OpenAL version/ > platform, or whatever. Or maybe I imagined it. It might have been a long time ago but it doesn't ring a bell for me. Erik -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] gitorious repositories for FlightGear and SimGear
On Saturday 19 September 2009 21:29:27 Tom P wrote: > But if bandwidth becomes a problem, we could provide read-only clones of > the fgdata repository. > git://source1.flightgear.org/fgdata > git://source2.flightgear.org/fgdata > .. > which pull automatically from the main repo. > In fact, 3 repos on mapserver.flightgear.org could easily be setup to > mirror gitorious.org instead of CVS. > > And in the end, gitorious already hosts Qt, I'd be surprised that we > require more bandwidth than that! I could add a server in Germany hosted at hetzner.de. I have about 700GB more disk space than I need and I got unlimited traffic (if I exceed 2TB, bandwidth gets reduced to 10MBit/s) of which I need just a few GB. So if this could help, I'd be glad to do it. Stefan signature.asc Description: This is a digitally signed message part. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On Sun, Sep 20, 2009 at 6:23 AM, Erik Hofman wrote: > > > > One other I've remember from looking at the code - for some reason we > > always positioned the listener at (0,0,0), and do a lot of work to > > transform world positions into a listener-relative basis. As I > > understand it, OpenAL can do that itself, i.e we could use a 'world' > > transform for most of the source positions (which would be simpler), > > and pass the FGViewer orientation as the OpenAL listener orientation. > > I *think* at that point the OpenAL and OSG local cartesian systems > > would be in-sync, which might help people generally understanding the > > code! > > True, and I expect it's also the reason why doppler didn't work > correctly (besides that the listener velocity wasn't updated while > OpenAL needs both the listener velocity and the source velocity for > proper calculation of the doppler effect). > There were also some issues with OpenAL 1.0, which were solved by 1.1, I recall sending a patch for this issue a while ago, I never check if it got accepted, etc, since life has been hectic :-) The issue of not setting listener velocity would of course also need addressing (doppler is all about relative velocity!). > What I'm planning on doing is let the SoundManager handle the OpenAL > context suff /and/ the listener properties and let the individual > SampleGroups handle positioning and handling the properties of all > associated samples. > I'm also interested in OpenAL and did a little work on this area, I'm very busy these days but I would like to continue contributing :) Matias D'Ambrosio -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Sound System redux
On 20 Sep 2009, at 10:23, Erik Hofman wrote: > True, and I expect it's also the reason why doppler didn't work > correctly (besides that the listener velocity wasn't updated while > OpenAL needs both the listener velocity and the source velocity for > proper calculation of the doppler effect). > > What I'm planning on doing is let the SoundManager handle the OpenAL > context suff /and/ the listener properties and let the individual > SampleGroups handle positioning and handling the properties of all > associated samples. Sounds great to me - should make MP much more exciting, as well as engine starting / failures. Regards, James -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Environment atmosphere.cxx, 1.3 , 1.4 atmosphere.hxx, 1.3, 1.4 enviro nment.cxx, 1.27, 1.28 environment.hxx , 1.11, 1.12
Hi John, I just fixed what appeared to me as a bug: mixing altitude_ft and altitude_m and wrong sign when computing temperature at sea level from temperature at altitude. Can you check and confirm that this is correct and reflects your original intention? Thanks, Torsten -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Environment atmosphere.cxx, 1.3, 1.4 atmosphere.hxx, 1.3, 1.4 environment.cxx, 1.27, 1.28 environment.hxx, 1.11, 1.12
On 09/20/09 08:52, Torsten Dreyer wrote: > Hi John, > > I just fixed what appeared to me as a bug: > mixing altitude_ft and altitude_m and wrong sign when computing temperature > at > sea level from temperature at altitude. > Can you check and confirm that this is correct and reflects your original > intention? I'm not in a position to check it at the moment. I'm happy to take your word for it. If the fix looks right to you, go for it. My code adheres to the convention that says the lapse is a positive number in the troposphere. Note the minus sign: d(temp)/d(height) = - lambda The opposite convention is encountered often enough to cause all sorts of confusion. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
