Re: [Flightgear-devel] /sim/navdb ?
Boris Koenig wrote: Hi ! Guess, who's here ;-) A quick question: I'm about to finish several smaller Nasal dialogs, now I wanted to add a simple flight planning dialog using Nasal, I thought I would find the necessary elements for the combo boxes under /sim/navdb within the property tree, but there does not seem to exist anything that I expected - is the data from the navaids file anywhere else exported within the property tree, or is it simply not yet there ? It's not there, and it probably never will be. The reason is simple, you would store too much data resident in memory which isn't needed more than 99% of the time. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
David Culp wrote: It seems to me the autopilot can't chose the correct pitch angle without some knowledge of the current pitch angle, or the airplane's performance. I think it wants to get a zero the angle-of-attack (alpha), which (in theory) could be done by increasing the speed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
På Mon, 20 Sep 2004 17:55:50 -0500, skrev David Culp <[EMAIL PROTECTED]>: Has anyone gotten "speed-with-pitch" autopilot mode to work properly using only PID controllers? (i.e. without outside help from the xmlauto internal code or some other system) I don't see how the speed-with-pitch controller in FlightGear's generic autopilot can work even in theory. I just tried the generic autopilot, and the speed-with-pitch mode didn't work as I expected. I haven't looked at the xml file, but I have a suggestion on how to design a speed-with pitch autopilot. I believe it can be done with only one PID controller (no cascading). Let us first analyze: we want to control the airspeed with the pitch. We assume that in order to increase airspeed we need to decrease the pitch angle and vice versa. We need to control the pitch angle. The first method that comes to mind is to use the elevator to control the pitch. So in order to increase airspeed we need to push the stick forward and to decrease airspeed we need to pull the stick back, decreasing and increasing the pitch angle respectively. Maybe we should name it speed-with-elevator instead! So our controller should look at the airspeed, apply forward pressure on the stick if we are too slow, or backward pressure if we are too fast. Isn't this similar to how a human pilot would do it! I would suggest to use airspeed as input to a PID controller, your desired airspeed as reference and the elevator control surface as output. I haven't tried this, so good luck! The first stage of the cascade assumes knowledge of the airplane's pitch angle, whereas the actual pitch angle could vary a lot. For example, I could be climbing at 250 knots with 10 degrees pitch, or I could be descending at 250 knots with -2 degrees pitch. If my speed increases to 255 knots the pitch in the first case should increase to about 12 degrees, and in the second case should increase to 0 degrees. It seems to me the autopilot can't chose the correct pitch angle without some knowledge of the current pitch angle, or the airplane's performance. My suggested autopilot does not care about actual pitch angle, it just increases it to slow down and decreases it to speed up. It doesn't have to bee more complicated than that. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
På Tue, 21 Sep 2004 12:00:09 +0200, skrev Roy Vegard Ovesen <[EMAIL PROTECTED]>: I would suggest to use airspeed as input to a PID controller, your desired airspeed as reference and the elevator control surface as output. I haven't tried this, so good luck! Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 with the Piper. You can start from there, and I'm sure that fine tuning will get better performance. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] /sim/navdb ?
Erik Hofman wrote:
Boris Koenig wrote:
Hi !
Guess, who's here ;-)
A quick question: I'm about to finish several smaller Nasal dialogs,
now I wanted to add a simple flight planning dialog using Nasal,
I thought I would find the necessary elements for the combo boxes
under /sim/navdb within the property tree, but there does not seem to
exist anything that I expected - is the data from the navaids file
anywhere else exported within the property tree, or is it simply not
yet there ?
It's not there, and it probably never will be.
woohoo - don't say that: I was just about to make a terrible mess of
the code ;-)
The reason is simple, you would store too much data resident in memory
which isn't needed more than 99% of the time.
okay, that's of course a point - otherwise it would definitely be
useful if one could request certain nav-data to be made available within
the property tree on demand, what do you think ?
Alternatively, I was thinking of either using a separate fgcommand that
pushes the data in the property tree when requested - so one would
basically still have something like:
/sim/navdb/vor
/sim/navdb/ndb
/sim/airports/
But it would only be an empty node, that would only be filled on demand
with the return value of a fgcommand that makes a certain request.
How about that ?
Also: does FG's current database contain the dafiff SID/STAR
information, too?
P.S.: I'm attaching a small change to Andy's dialog.cxx that I needed
to make so that it enables XML/Nasal-dialogs to also contain
puLargeInput boxes.
The text will be retrieved/buffered from/within a specified
property tree, like:
100
100
200
100
/gui/path-to-text-node/contents
15
true
I hope that the modification is alright and that it
doesn't screw things up ;-)
I would also like to add support for puPopup's as well
as exporting the menubar to the property tree - so that
it can be populated/changed dynamically - any objections ?
And I assume, the preferable way to send you future suggestions
for patches is by private mail rather than using the mailing list ? :-)
Boris
--- dialog.cxx.orig Tue Sep 21 12:50:26 2004
+++ dialog.cxx Tue Sep 21 12:47:59 2004
@@ -385,6 +385,22 @@
dial->setWrap(props->getBoolValue("wrap", true));
setupObject(dial, props);
return dial;
+} else if (type == "textbox") {
+ int slider_width = props->getIntValue("slider", parentHeight);
+ if (slider_width==0) slider_width=20;
+ puLargeInput * puTextBox = new puLargeInput ( x , y, x+width, x+height,2,
slider_width );
+
+ if (props->hasValue("editable"))
+ {
+ if (props->getBoolValue("editable")==false)
+ puTextBox->disableInput();
+ else
+ puTextBox->enableInput();
+ }
+
+ setupObject(puTextBox,props);
+return puTextBox;
+
} else if (type == "select") {
vector value_nodes;
SGPropertyNode * selection_node =
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] /sim/navdb ?
Boris Koenig wrote: Erik Hofman wrote: Boris Koenig wrote: where else exported within the property tree, or is it simply not yet there ? It's not there, and it probably never will be. woohoo - don't say that: I was just about to make a terrible mess of the code ;-) No need, that has already been done. It turned out to be unsatisfactory after all. The reason is simple, you would store too much data resident in memory which isn't needed more than 99% of the time. okay, that's of course a point - otherwise it would definitely be useful if one could request certain nav-data to be made available within the property tree on demand, what do you think ? Alternatively, I was thinking of either using a separate fgcommand that pushes the data in the property tree when requested - so one would basically still have something like: /sim/navdb/vor /sim/navdb/ndb /sim/airports/ But it would only be an empty node, that would only be filled on demand with the return value of a fgcommand that makes a certain request. How about that ? What would be an idea is to use an fgcommand that looks at (for example) /sim/navdb/id and returns the data of that particular id in /sim/navdb/vor et all. I would also like to add support for puPopup's as well as exporting the menubar to the property tree - so that it can be populated/changed dynamically - any objections ? Popup dialogs should already be supported. Generating a dynamic menu structure might be harder than you think, the best option is a triggered reload I guess (which is already supported, see Debug->Reload GUI). Erik Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] /sim/navdb ?
Erik Hofman writes: > > Boris Koenig wrote: > > > > A quick question: I'm about to finish several smaller Nasal dialogs, > > now I wanted to add a simple flight planning dialog using Nasal, > > I thought I would find the necessary elements for the combo boxes > > under /sim/navdb within the property tree, but there does not seem to > > exist anything that I expected - is the data from the navaids file > > anywhere else exported within the property tree, or is it simply not > > yet there ? > > It's not there, and it probably never will be. > The reason is simple, you would store too much data resident in memory > which isn't needed more than 99% of the time. Hmm... a simple disk based database indexed by a new field which was the tile id of the object should be plenty quick enough for this type of thing with out to much of a memory hit Searches would then only need be made for those tiles of interest which would be dramatically faster then searching the 'world' One might get better results using a more sophisticated index such as a dedicated RTree if necessary but a tile based scheme would fit nicely with the existing 'indexing' Then again the current DB is about the size of the highres textures so my guess is that until the DB is significantly upgraded it could just be placed into memory < you would still want some kind of spatial indexing though > Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] /sim/navdb ?
Erik Hofman wrote:
Boris Koenig wrote:
woohoo - don't say that: I was just about to make a terrible mess of
the code ;-)
No need, that has already been done.
what...the feature or the 'mess' ? :-)
Alternatively, I was thinking of either using a separate fgcommand that
pushes the data in the property tree when requested - so one would
basically still have something like:
/sim/navdb/vor
/sim/navdb/ndb
/sim/airports/
What would be an idea is to use an fgcommand that looks at (for example)
/sim/navdb/id and returns the data of that particular id in
/sim/navdb/vor et all.
right, that's exactly what I was talking about - one would only need
to use an accessor string within the property tree.
The problem is then though, that the navaids db certainly contains
various navaids using the same ID - so the fgcommand would need
to return an _array of replies_, which will then be checked for their
positional data, in order to make sure that you retrieved the correct
navaid.
I would also like to add support for puPopup's as well
as exporting the menubar to the property tree - so that
it can be populated/changed dynamically - any objections ?
Popup dialogs should already be supported.
I wasn't talking of 'dialogs' but rather menus:
context menus - I don't think anybody else would
really require it, but I pretend to need it ;-)
Also, it's not that much of a change, either.
Generating a dynamic menu structure might be harder than you think,
Hmm, you may be right - I haven't yet really looked into the source
code.
Anyway, so let's share what I "think":
=> export the entire menubar.xml file with its items
into something like
/gui/menubar/structure
Now all menus and menu items would be stored in that path within
the property tree.
So the property tree holds then something like this:
/gui/menubar/structure/menu[0]/label
=> "File"
/gui/menubar/structure/menu[0]/item[0]/label"
=> "Load"
/gui/menubar/structure/menu[0]/item[0]/binding[0]/command[0]"
=> "nasal"
/gui/menubar/structure/menu[0]/item[0]/binding[0]/command[0]/script"
=> print("..");
which would be the equivalent of:
File
Load
nasal
print("..");
That way, the whole menubar.xml could be put into the property tree,
and could easily be modified using a nasal script, that can either
change an existing menu/-item or simply add new ones by using the
absolute paths like shown above.
So, one would ultitmately have "self-registering" nasal scripts.
Regarding the updating of the menubar itself one would either need to
fire an event if any node changes and do the updating automatically
OR use a separate fgcommand that re-creates the menubar based on
what it finds in the corresponding sub-path of the property tree.
the best option is a triggered
reload I guess (which is already supported, see Debug->Reload GUI).
yes, right - I know, but that would require a (manually) modified
menubar.xml, but I don't want to modify it statically, rather I
envision something like the following:
drop a nasal file into $FG_ROOT/Nasal, which then
get's loaded as module.
now this module needs to customize the menubar,
because it has some nifty new dialog or other
functionality, USUALLY this would require to
MANUALLY edit menubar.xml and add a the stuff.
WITH such an exported property tree, a Nasal script
could make its own commands available to the user,
without the need to modify the menubar.xml.
The motivation behind all this is, that I have a couple of smaller
nasal scripts that I would like to "auto-add" themselves on demand.
PLIB/PUI does currently not support submenus, so one would ultimately
end up having pretty unsorted menus, the more stuff gets added, the
less items can you place there - but having the possibility to
dynamically populate the menubar would mean that scripts can
compensate for the lack of submenus.
But you are of course right: I haven't yet really looked into it,
and might think that it is easier than it really is ...
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] /sim/navdb ?
Jim Wilson writes: > > Norman Vine said: > > > > > Hmm... a simple disk based database indexed by a new field > > which was the tile id of the object should be plenty quick enough > > for this type of thing with out to much of a memory hit > > > > Searches would then only need be made for those tiles of interest > > which would be dramatically faster then searching the 'world' > It would be kind of cool to be able to have a property system wrapper for data > files like this, that swapped the interesting parts in and out as needed. The > "indexing" could be designed to optimise this, for each type of layout. My guess is that once the tile-id field was added to the DB then most of the existing background scenery paging mechanism would work as is for the in memory part of the DB as just another 'task' for the thread Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] /sim/navdb ?
Norman Vine said: > Erik Hofman writes: > > > > Boris Koenig wrote: > > > > > > A quick question: I'm about to finish several smaller Nasal dialogs, > > > now I wanted to add a simple flight planning dialog using Nasal, > > > I thought I would find the necessary elements for the combo boxes > > > under /sim/navdb within the property tree, but there does not seem to > > > exist anything that I expected - is the data from the navaids file > > > anywhere else exported within the property tree, or is it simply not > > > yet there ? > > > > It's not there, and it probably never will be. > > The reason is simple, you would store too much data resident in memory > > which isn't needed more than 99% of the time. > > Hmm... a simple disk based database indexed by a new field > which was the tile id of the object should be plenty quick enough > for this type of thing with out to much of a memory hit > > Searches would then only need be made for those tiles of interest > which would be dramatically faster then searching the 'world' > > One might get better results using a more sophisticated index such > as a dedicated RTree if necessary but a tile based scheme would > fit nicely with the existing 'indexing' > > Then again the current DB is about the size of the highres textures > so my guess is that until the DB is significantly upgraded it could > just be placed into memory > < you would still want some kind of spatial indexing though > > It would be kind of cool to be able to have a property system wrapper for data files like this, that swapped the interesting parts in and out as needed. The "indexing" could be designed to optimise this, for each type of layout. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] That grid again ?
On 9/20/04 at 10:01 PM Mat Churchill wrote: >Hi All, > >I am going to have a second shot at photo scenery and have been looking >at the last way I did it. >I have asked this question before, but wonder if there is anyone out >there who knows where I can find out how terrain texture tiles are >placed in FG. > >It looks as if they are placed by FG and not during scenery building by >TG. I say this as when I open up scenery tiles in FGSD there is >definitely no existing series of squares. Yet the terrain textures are >laid over the scenery in a fixed grid that doesn't change however I >build the scenery. Here is a screenshot of the "grid" (made by using all >black terrain texture tiles with a single pixel white edge) > >http://www.projects.34sp.com/Flightgear/tn/a-Black-grid.jpg.html > >Yet TG does define what terrain texture goes where. So there you go I'm >confused. > >Basically last time I spent ages copying this grid by hand, then >building it into the scenery using TG. A fuller understanding of how >those terrain textures are placed is going to hopefully enable me to >come up with an at least partially automated way of placing photo >scenery tiles. > >Is there a LOD system for terrain textures ? > >Regards > > The texture co-ordinates are calculated by TerraGear. If you pass in --useUKgrid on the command line to the construct stage then it will align them with the OS grid, possibly making your automated texture placing within the UK slightly easier. I haven't tested this for a while though - it might have been broken by now! Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
On 9/17/04 at 2:04 PM John Wojnaroski wrote:
>- Original Message -
>From: "Jon Stockill" <[EMAIL PROTECTED]>
>To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
>Sent: Friday, September 17, 2004 11:54 AM
>Subject: Re: [Flightgear-devel] A voice for FG
>
>
>> John Wojnaroski wrote:
>> > Hi,
>> >
>> > The last month or so I've been working with adding synthetic speech
and
>> > voice recognition to my 747 project. The results have been quite good;
>> > unfortunately it's kind of hard to demonstrate or display the results.
>> >
>> > Jim Brennan is preparing a corpus of messages and ATC phrases which
>will
>be
>> > used to create a LM (Language Model) for speech recognition and the
>> > synthetic speech voices come from a variety of sources -- most
notably,
>the
>> > FestVox folks at CMU, MBROLA, and the OGI-Festival project at CSLU.
>>
>> I was working with the pre-release of festival 2.0 at work last week,
>> and the new synthesis methods and voices that are available in that
>> release sound particularly impressive. I did think of the possibility of
>> using it for air traffic control, if not "live" then as an easy method
>> to generate a batch of samples for use in a similar way to the way ATIS
>> works at the moment.
>>
>The approach that I've taken is to start a festival server on a networked
>machine and a small client program that receives a text message as a
string
>, stuffs it into a festival protcol wrapper and calls the
>festivalStringToWave() method. This also will allow you to send control
>commands and files to the server to change voices, LMs, etc..
>
>"../bin/festival --server loopback" starts the server and any client on
>the
>local machine can connect by default. Connections over a LAN require a
>small
>Scheme script to add users to the festival_access_list as part of the
>argument list.
>
>The client program then has a few lines of socket code to connect to FG.
On
>the FG side all you need is something to send a text string over the
>socket.
>Something like FGVoice::fg_say_mesg("this is a test"); There are a couple
>of
>good examples in the /examples/ directory which I used to create a
>"atc_net_demo.cpp" application.
>
>The voice recognition is just as easy (actually easier to set up) but
>training the model, building the Acoustic model, and the dictionary plus
>any
>special phones is a little more envolved. If you don't mind a bit of a
>delay
>(around 2-3 sec) to decode the audio, you can use the existing models and
>get pretty good results. The resultant text string is sent to the AI
>controller where it is parsed into tokens and analyzed(compiled?).
>
>I'm not sure how all of this would fit into FG. I suspect the easiest way
>would be to create a voice object and a few methods and leave it up to the
>individual user if they want to setup the TTS festival package or ASR
>programs.
>
This all sounds very exciting, especially the encouraging results from the
voice recognition stage, and the fact that Jon thinks that Festival 2 is
sounding pretty good. Could you send me the code you've got so far for
sending strings across to FG?
I'm a bit unclear which parts you are actually working on. Are you working
on the decoding of the speech to text-strings only so far, or have you
actually started on logically decoding the text strings for ATC-AI? This
is the part I'm currently in deep thought about.
A few random thoughts. Speech recognition for ATC ought to be easier than
the general case, since the smaller vocabulary ought to mean that better
guesses can be made, if this sort of thing can be specified to the ASR
engine.
Having it on another PC could be nice from the point of view that the
engine sound from the FG PC can come from the speakers - with ATC from the
TTS/ASR PC put though headphones to fairly realistically simulate the real
environment.
I guess eventually this support could be optionally compiled into FG as
well.
Cheers - Dave
This message has been scanned but we cannot guarantee that it and any
attachments are free from viruses or other damaging content: you are
advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
David Luff wrote: This all sounds very exciting, especially the encouraging results from the voice recognition stage, and the fact that Jon thinks that Festival 2 is sounding pretty good. As I mentioned earlier you can make up your own mind: there are numerous examples available at: http://www.cstr.ed.ac.uk/projects/festival/demos.html http://www-2.cs.cmu.edu/~awb/festival_demos/general.html - including the possibility to "remote-control" festival via a simple CGI: http://festvox.org/voicedemos.html http://www-2.cs.cmu.edu/~awb/festival_demos/userin.html ... so that the synthesized speech is returned as wav/mp3 file. Some of these examples sound pretty unspectacular and actually exactly like what you'd normally expect from a TTS, unlike others that are really impressive - these are then created using an approach that uses mathematically enhanced fragments of real audio data - this is specifically meant to be used in areas where there's only a certain subset of vocabulary expected (sounds suitable for our task). I think they call it "Language (specific) Domain Modelling" or something like that, will have to check their homepage for that, though - here: http://festvox.org/ldom/index.html Could you send me the code you've got so far for sending strings across to FG? if I didn't get him wrong, he was only just about to consider making a stab at it, not really writing anything specific for FG yet - also, my impression was that he was firstly going to send strings *from* FG to the TTS ? I'm a bit unclear which parts you are actually working on. Are you working on the decoding of the speech to text-strings only so far, or have you actually started on logically decoding the text strings for ATC-AI? This is the part I'm currently in deep thought about. Would you mind sharing more of your 'deep thoughts' ? :-) I would really love to hear about other suggestions for approaches to deal with the AI part. A few random thoughts. Speech recognition for ATC ought to be easier than the general case, since the smaller vocabulary ought to mean that better guesses can be made, if this sort of thing can be specified to the ASR engine. That's entirely correct, the latter is indeed possible - with festival, too: This is what I referred to as 'LDM', this is also where the results are really REMARKABLE (there are examples about that, too) - this is all based on building a domain specific phonetic database - so the overall quality will depend whether you have a suitable database or not: http://www.festvox.org/dbs/index.html For the LDM part you need to have REAL AUDIO data of the relevant domain available and have another application process it, that creates a mathematical model of the most frequently encountered phonetical patters, these are then used to create a "language domain specific" database for speech synthesis. So this is the drawback - you need to have plenty of audio data available in order to get good results, but on the other hand it shouldn't be all that difficult to get our hands on a couple of hours of ATC recordings: there are numerous free ATC streaming servics on the web, one would only need to record these and feed them into a LDM creation application. But on the other hand, quality is a pretty determining factor, so you cannot simply use any ATC stream - like all those that were recorded using a simple scanner, one would rather need to use high quality recordings of ATC <-> Pilot conversations in order to create a usable domain model, so one would prefer those streams that are being made available by airports/centers themselves... What I found particularly interesting when I browsed the festival pages a couple of days ago, though was that festival seems to have already components available that would take care of what I referred to as the "dialecting part", take a look at: http://www-2.cs.cmu.edu/~awb/festival_demos/sable.html So, in that regard there would be no need to make up anything :-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
Boris Koenig wrote: David Luff wrote: This all sounds very exciting, especially the encouraging results from the voice recognition stage, and the fact that Jon thinks that Festival 2 is sounding pretty good. As I mentioned earlier you can make up your own mind: there are numerous examples available at: http://www.cstr.ed.ac.uk/projects/festival/demos.html http://www-2.cs.cmu.edu/~awb/festival_demos/general.html - including the possibility to "remote-control" festival via a simple CGI: http://festvox.org/voicedemos.html http://www-2.cs.cmu.edu/~awb/festival_demos/userin.html ... so that the synthesized speech is returned as wav/mp3 file. Some of these examples sound pretty unspectacular and actually exactly like what you'd normally expect from a TTS, unlike others that are really impressive - these are then created using an approach that uses mathematically enhanced fragments of real audio data - this is specifically meant to be used in areas where there's only a certain subset of vocabulary expected (sounds suitable for our task). Those demos are based on festival 1.4 - the prerelease of 2.0 includes a synthesis module called multisyn, which is a great improvement on the older modules. http://flightgear.stockill.org.uk/testing/atis.wav contains the synthesised text of an atis transmission using one of the multisyn voices. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
Jon Stockill wrote: Those demos are based on festival 1.4 - the prerelease of 2.0 includes a synthesis module called multisyn, which is a great improvement on the older modules. http://flightgear.stockill.org.uk/testing/atis.wav contains the synthesised text of an atis transmission using one of the multisyn voices. Thanks for the clarification and the example - it does indeed sound already quite usable, particularly taking into account that your example file did not even make use of any customized language model ! Now, I am really tempted to look for online ATC streams in order to have festival speak to me even more aviation-like ;-) I only wonder, how long the actual calculation of a new language model takes - any ideas ? Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
- Original Message -
From: "David Luff" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Tuesday, September 21, 2004 6:49 AM
Subject: Re: [Flightgear-devel] A voice for FG
>
>
> On 9/17/04 at 2:04 PM John Wojnaroski wrote:
>
> >- Original Message -
> >From: "Jon Stockill" <[EMAIL PROTECTED]>
> >To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
> >Sent: Friday, September 17, 2004 11:54 AM
> >Subject: Re: [Flightgear-devel] A voice for FG
> >
> >
> >> John Wojnaroski wrote:
> >> > Hi,
> >> >
> >> > The last month or so I've been working with adding synthetic speech
> and
> >> > voice recognition to my 747 project. The results have been quite
good;
> >> > unfortunately it's kind of hard to demonstrate or display the
results.
> >> >
> >> > Jim Brennan is preparing a corpus of messages and ATC phrases which
> >will
> >be
> >> > used to create a LM (Language Model) for speech recognition and the
> >> > synthetic speech voices come from a variety of sources -- most
> notably,
> >the
> >> > FestVox folks at CMU, MBROLA, and the OGI-Festival project at CSLU.
> >>
> >> I was working with the pre-release of festival 2.0 at work last week,
> >> and the new synthesis methods and voices that are available in that
> >> release sound particularly impressive. I did think of the possibility
of
> >> using it for air traffic control, if not "live" then as an easy method
> >> to generate a batch of samples for use in a similar way to the way ATIS
> >> works at the moment.
> >>
> >The approach that I've taken is to start a festival server on a networked
> >machine and a small client program that receives a text message as a
> string
> >, stuffs it into a festival protcol wrapper and calls the
> >festivalStringToWave() method. This also will allow you to send control
> >commands and files to the server to change voices, LMs, etc..
> >
> >"../bin/festival --server loopback" starts the server and any client on
> >the
> >local machine can connect by default. Connections over a LAN require a
> >small
> >Scheme script to add users to the festival_access_list as part of the
> >argument list.
> >
> >The client program then has a few lines of socket code to connect to FG.
> On
> >the FG side all you need is something to send a text string over the
> >socket.
> >Something like FGVoice::fg_say_mesg("this is a test"); There are a couple
> >of
> >good examples in the /examples/ directory which I used to create a
> >"atc_net_demo.cpp" application.
> >
> >The voice recognition is just as easy (actually easier to set up) but
> >training the model, building the Acoustic model, and the dictionary plus
> >any
> >special phones is a little more envolved. If you don't mind a bit of a
> >delay
> >(around 2-3 sec) to decode the audio, you can use the existing models and
> >get pretty good results. The resultant text string is sent to the AI
> >controller where it is parsed into tokens and analyzed(compiled?).
> >
> >I'm not sure how all of this would fit into FG. I suspect the easiest way
> >would be to create a voice object and a few methods and leave it up to
the
> >individual user if they want to setup the TTS festival package or ASR
> >programs.
> >
>
>
> This all sounds very exciting, especially the encouraging results from the
> voice recognition stage, and the fact that Jon thinks that Festival 2 is
> sounding pretty good. Could you send me the code you've got so far for
> sending strings across to FG?
>
Actually, there are three parts --- the ASR that converts speech to text
(that runs on my laptop) and sends the text string over the LAN to the AI
app that analyzes and generates a response and sends the text over to the
festival engine (TTS) for conversion back to audio. I'll send along more
details via private mail and attach the tar files.
> I'm a bit unclear which parts you are actually working on. Are you
working
> on the decoding of the speech to text-strings only so far, or have you
> actually started on logically decoding the text strings for ATC-AI? This
> is the part I'm currently in deep thought about.
>
Working on the speech to text and text to speech ends, the middle ATC/AI is
the really tough part. Have you ever looked at www.vatsim.org or
www.ivao.org ? A different approach using real "actors" to create a virtual
world. But, alas, it's all MS based...
> A few random thoughts. Speech recognition for ATC ought to be easier than
> the general case, since the smaller vocabulary ought to mean that better
> guesses can be made, if this sort of thing can be specified to the ASR
> engine.
Yes, yes, and yes
>
> Having it on another PC could be nice from the point of view that the
> engine sound from the FG PC can come from the speakers - with ATC from the
> TTS/ASR PC put though headphones to fairly realistically simulate the real
> environment.
>
Exactly how I'm setting up my sim... and it does impart a better sense and
feel; especially if you mount the engine spe
Re: [Flightgear-devel] A voice for FG
On Tue, 21 Sep 2004 16:02:34 +0100 Jon Stockill <[EMAIL PROTECTED]> wrote: > > Those demos are based on festival 1.4 - the prerelease of 2.0 includes a > > synthesis module called multisyn, which is a great improvement on the > older modules. http://flightgear.stockill.org.uk/testing/atis.wav > contains the synthesised text of an atis transmission using one of the > multisyn voices. That's a great Cleveland accent! :) Seriously, this is pretty cool. If it's being run on the same machine at fgfs, what is the overhead involved? Would framerates be expected to drop into the dirt while the speech is being done? -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear pgpAgBhA98vKc.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problems Compiling with Cygwin again
Hi ! I wrote some weeks ago in the users list, that i have problems with compiling with cygwin. I have tried several things including a new installation of Windows XP and Cygwin. I installed the cygwin packages described in the documatation on the flightgear website. I`m using the newest versions of Simgear, Flightgear, Plib, openal. I downloaded them today. Plib and openal are compiling ok. But the sound files called testopenal1 of simgear wont compile It seems that Simgear does not link to Openal. So I added -lopenal manually to the makefile. After that i get the next error. The output then looks like this: Making all in sound make[3]: Entering directory `/usr/local/source/SimGear/simgear/sound' g++ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o openal_test2.exe openal_test2.o . ./../simgear/sound/libsgsound.a ../../simgear/debug/libsgdebug.a ../../simgear/m isc/libsgmisc.a ../../simgear/structure/libsgstructure.a -L/usr/local/lib -lopen al -lwinmm -ldsound -ldxguid -lole32 openal_test2.o(.text+0xd2): In function `_ZTv0_n12_N9logstreamD0Ev': /usr/local/source/SimGear/simgear/sound/../../simgear/debug/logstream.hxx: undef ined reference to `__imp__alSourcef' openal_test2.o(.text+0xe5):/usr/local/source/SimGear/simgear/sound/../../simgear /debug/logstream.hxx: undefined reference to `__imp__alGetError' openal_test2.o(.text+0x1d4):/usr/local/source/SimGear/simgear/sound/../../simgea r/debug/logstream.hxx: undefined reference to `__imp__alSourcef' openal_test2.o(.text+0x1e7):/usr/local/source/SimGear/simgear/sound/../../simgea r/debug/logstream.hxx: undefined reference to `__imp__alGetError' I really appreciate any help. Im a bit desperate I want to use Flightgear for my master thesis. Being unable to compile for weeks now counts as lost time for my thesis. I want to use it as FlightSimulator for a Fitnessmachine with which u can simulate flying like a bird and train by doing so. Thx in advance for any clues. Cu, Floh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Fw: Voice stuff (sans attached)
FYI if anyone wants the files (about 200k) give a holler you can run the whole mess on a single machine along with FG. The hit to the frame rate is TBD. - Original Message - From: "John Wojnaroski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 21, 2004 9:44 AM Subject: Voice stuff > Hi David, > > Attached are two files: > > comm_747 is a really bad hack for the CMU Sphinx ASR engine to create a text > string and sent it out on the network to the "atc_server" > > voice.tgz is more hacking to send a text string to the festival server.. > lines 73 to 76 is my highly sophisticated AI /ATC controller ;-) > it untars as /Voice > > You can run festival as a server "../bin/festival --server" on the same > machine you run "atc_net_demo" and the audio will be produced on that > machine or you can uncomment lines 295-309 and also send a .wav file back to > the client machine. > > A quick recap: > Machine #1 runs sphinx2 which receives the audio input from the user, > converts it to text and sends it over to Machine #2 which parses the text > string into tokens and does it's AI/ATC stuff, formulates a text response > and passes that to the festival server (in this case on 127.0.0.1) which > creates the audio file and outputs it to the local soundcard. If you run the > festival server on a seperate network machine or back on #1 you need to > create a short .scm script to add the user to the festival access list as in > atc.scm > > You need to upload the ASR sphinx2 stuff and TTS festival stuff from CMU or > wherever. If you need some help or tips in that area give a holler... > http://linux-sound.org/speech.html is a list of speech related websites you > might find useful. In particular-- > the Festival set, XVoice, Sphinx, and MBROLA. I'm using the > > You'll find http://www.speech.cs.cmu.edu/tools/lmtool.html quite useful for > creating a LM and phonelist for the ASR program. With the smaller > dictionaries voice recognition is very good but if you mumble a lot (like I > do) the XVoice folks have a wiki page with instructions on how to add a > voice trainer and improve/tailor the AM for individual speech patterns. > > Setting up the programs takes a little work. You can use the AM provided > with sphinx2, but you'll get much better results if you upload and install > the hub4-2000-11-17-1 model. And you will need to create a LM that contains > ATC phrases and words > > Good luck, again you've got my email, don't hesitate if you need help or > have questions. > > Regards > John W. > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
On Tue, 21 Sep 2004 11:27:37 -0400, Chris wrote in message <[EMAIL PROTECTED]>: > On Tue, 21 Sep 2004 16:02:34 +0100 > Jon Stockill <[EMAIL PROTECTED]> wrote: > > > > Those demos are based on festival 1.4 - the prerelease of 2.0 > > includes a > > > > synthesis module called multisyn, which is a great improvement on > > the older modules. > > http://flightgear.stockill.org.uk/testing/atis.wav contains the > > synthesised text of an atis transmission using one of the multisyn > > voices. > > That's a great Cleveland accent! :) ..if you like a draaawl, try sox -V atis.wav atis.ogg speed 0.5 # ;-). Really amazing how a few extra seconds spent on the tape adds to speeding up getting-the-message, try it with speeds around .8 to .9. > Seriously, this is pretty cool. If it's being run on the same machine > at fgfs, what is the overhead involved? Would framerates be expected > to drop into the dirt while the speech is being done? > > -c > -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
> > I would suggest to use airspeed as input to a PID controller, your > > desired airspeed as reference and the elevator control surface as output. > > I haven't tried this, so good luck! > > Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 > with the Piper. You can start from there, and I'm sure that fine tuning > will get better performance. Thanks Roy, it works better now, but still not enough to prevent crashing. It looks like I'll still need an external monitor to clamp the pitch angle. For instance, if I'm doing an idle descent at 250 kts and reset the speed to 300, I need to keep the airplane from going straight down. Dave -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Problems Compiling with Cygwin again
Florian Schießl > Sent: Tuesday, September 21, 2004 4:51 PM > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Problems Compiling with Cygwin again > > > Hi ! > I wrote some weeks ago in the users list, that i have problems with > compiling with cygwin. > I have tried several things including a new installation of > Windows XP > and Cygwin. > I installed the cygwin packages described in the documatation on the > flightgear website. > I`m using the newest versions of Simgear, Flightgear, Plib, openal. I > downloaded them today. > > Plib and openal are compiling ok. But the sound files called > testopenal1 > of simgear wont compile > > It seems that Simgear does not link to Openal. So I added -lopenal > manually to the makefile. > > After that i get the next error. The output then looks like this: > > Making all in sound > make[3]: Entering directory `/usr/local/source/SimGear/simgear/sound' > g++ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -o openal_test2.exe > openal_test2.o . > ./../simgear/sound/libsgsound.a ../../simgear/debug/libsgdebug.a > ../../simgear/m > isc/libsgmisc.a ../../simgear/structure/libsgstructure.a > -L/usr/local/lib -lopen > al -lwinmm -ldsound -ldxguid -lole32 > openal_test2.o(.text+0xd2): In function `_ZTv0_n12_N9logstreamD0Ev': > /usr/local/source/SimGear/simgear/sound/../../simgear/debug/lo > gstream.hxx: > undef > ined reference to `__imp__alSourcef' > openal_test2.o(.text+0xe5):/usr/local/source/SimGear/simgear/s > ound/../../simgear > /debug/logstream.hxx: undefined reference to > `__imp__alGetError' > openal_test2.o(.text+0x1d4):/usr/local/source/SimGear/simgear/ > sound/../../simgea > r/debug/logstream.hxx: undefined reference to > `__imp__alSourcef' > openal_test2.o(.text+0x1e7):/usr/local/source/SimGear/simgear/ > sound/../../simgea > r/debug/logstream.hxx: undefined reference to `__imp__alGetError' > > I really appreciate any help. Im a bit desperate I want to use > Flightgear for my master thesis. Being unable to compile for > weeks now > counts as lost time for my thesis. > I want to use it as FlightSimulator for a Fitnessmachine with which u > can simulate flying like a bird and train by doing so. > > Thx in advance for any clues. > > Cu, Floh > Have you downloaded and installed openal_cyg.tgz from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ It still seems to be required for Cygwin. The error with test openal_test2.exe or something like it was present in an earlier version of simgear. Have you definitely downloaded the latest version of Simgear? FGFS does compile under Cygwin - I did it this morning. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fw: Voice stuff (sans attached)
On Tue, 21 Sep 2004 09:58:30 -0700, John wrote in message <[EMAIL PROTECTED]>: > FYI > > if anyone wants the files (about 200k) give a holler ..yhooo! ;-) > you can run the whole mess on a single machine along with FG. The hit > to the frame rate is TBD. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Fw: Voice stuff (sans attached)
http://homepages.westminster.org.uk/giles.robertson/fgfsvoice.htm Giles Robertson -Original Message- From: Arnt Karlsen [mailto:[EMAIL PROTECTED] Sent: 21 September 2004 18:52 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Fw: Voice stuff (sans attached) On Tue, 21 Sep 2004 09:58:30 -0700, John wrote in message <[EMAIL PROTECTED]>: > FYI > > if anyone wants the files (about 200k) give a holler ..yhooo! ;-) > you can run the whole mess on a single machine along with FG. The hit > to the frame rate is TBD. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
David Culp said: > > > I would suggest to use airspeed as input to a PID controller, your > > > desired airspeed as reference and the elevator control surface as output. > > > I haven't tried this, so good luck! > > > > Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 > > with the Piper. You can start from there, and I'm sure that fine tuning > > will get better performance. > > Thanks Roy, it works better now, but still not enough to prevent crashing. It > looks like I'll still need an external monitor to clamp the pitch angle. For > instance, if I'm doing an idle descent at 250 kts and reset the speed to 300, > I need to keep the airplane from going straight down. > You might also want to look at the lookahead feature, similar to one used in the 747 autothrottle configuration, especially for larger aircraft. While overshot can be tuned for with PID, this seems to help a bit by directly incorporating the rate at which you are approaching the goal. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
Boris Koenig wrote: Jon Stockill wrote: Those demos are based on festival 1.4 - the prerelease of 2.0 includes a synthesis module called multisyn, which is a great improvement on the older modules. http://flightgear.stockill.org.uk/testing/atis.wav contains the synthesised text of an atis transmission using one of the multisyn voices. Thanks for the clarification and the example - it does indeed sound already quite usable, particularly taking into account that your example file did not even make use of any customized language model ! Yes, that's the result of just feeding the text of an atis report I found with google straight into the text2wave script. I'm sure it could be improved quite a lot just by playing around with punctuation to get the correct cadence. I only wonder, how long the actual calculation of a new language model takes - any ideas ? None at all I'm afraid. I just needed festival to add easily generated speech to a telephone IVR project. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with ballistic sub-model
On Monday 20 September 2004 08:39, Vivian Meazza wrote:
{snip...]
> Lee,
>
> Here's some pics off the effects I obtained:
>
> http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_drag-full_g
>ravity.jpg
>
> http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-acc
>elerating.jpg
>
> http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bom
>bs_overtaking. jpg
>
> http://myweb.tiscali.co.uk/vmeazza/FlightGear/zero_gravity-bra
>king.jpg
>
> I hope that you can achieve the same.
>
> Regards
>
> Vivian
Sadly, no. Those pics are pretty much what I was hoping to see
here but it's just not happening. This is very odd.
I could post a pic showing the a/c after braking, with the string
of bombs behind and the cluster around the nose (which would
show that it had moved, while releasing bombs and was now
stationary) but is there any point?
I'm a bit reluctant to do a full fresh cvs checkout because I'd
have to also get a new base package too, wouldn't I? Still on
dial-up here so I'd like to avoid having to do that if possible.
If I delete the source code directories from my local cvs and
then did an update, would it replace anything that was missing?
I guess I could try getting FG installed on one of my other
workstations and see if I get the same results.
I did try setting a more verbose log-level but didn't see
anything there either.
This is such a strange problem. Because there are no apparent
run-time errors it's difficult not to conclude that there's a
logic error in the code but the fact it works elsewhere rules
that out.
Feeling pretty stumped here:-/
LeeE
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal'ing ...
[Sorry I've been so long getting back to this; I had to go to Japan on
short notice and this is the first chance I've had in the hotel room
to catch up on personal stuff without jet-lag. :)]
Boris Koenig wrote:
> I don't seem to be able to access a method like gui.Widget.new()
> from an object defined in another module, even though I _think_ ;-)
> I'm doing the right thing, basically that is:
>
> two ".nas"-files stored in /Nasal/ whose contents will be made
> available as modules within Nasal.
This is an ordering issue. Remember that "loading" and "running"
a script are the same thing in Nasal. If the test2 module loads
before test1, then test1 will not be initialized when test2 tries
to use it.
Some of the Nasal files get around this issue by doing their
initialization work in a timer that is registered to run after a
zero-length timeout. Look for a function called INIT() in several
scripts; I believe one of them has an extensive comment talking about
how the mechanism works.
What would be a better, permanent solution would be to support an
"import" feature. Thus, test2 could execute something like
import("test1") which would stop execution and load the test1 module
before returning. Note that this is another reason to support
recursive interpreter contexts, which I talked about earlier.
> But I did meanwhile play around with the mechanism that you used in
> that example, and I'm surprised to see that it _seems_ already quite
> possible to dynamically create a gui ... I haven't yet tried to
> create every PUI - control, but so far it's already extremely
> usable.
The current GUI system creates an interface out of a property tree.
That tree can be dynamically created with a Nasal script, so yes: what
you want to do is possible. Not every PUI binding is supported,
though. For example, you can create the interface dynamically, but
you can't change its structure at runtime (although you can destroy
and re-create the dialog, which might be good enough for many
purposes).
> > If those get used, you can end up in a situation where the "old"
> > and "new" versions of the file are in use simultaneously.
> > Likewise, think of timers registered by
> > the "old" version that get run after the new one is loaded.
>
> but, this shouldn't happen if the other Nasal code gets reloaded, too -
> right ?
No. Timers and other references are not stored symbolically. That
is, they are stored in C++ space as a NaRef object, which contains a
pointer into the garbage collected Nasal storage. The timer does not
store something like "module.SomeFunction()" which would do the symbol
lookup when executed. If you reload a module, references to the older
objects will stay alive.
> Also, what's the preferred way of implementing a basic "event loop"
> using Nasal, I've played around with this by using either a
> normal loop, or a timer - what's the best choice to poll a certain
> node from the property tree and act upon it assuming a certain
> value ?
You can't "spin" in a Nasal loop at the moment; you will just hang the
simulator. This would require the "multiple contexts" feature to
implement -- the Nasal subsystem could let a script execute for N
instructions and then put it on a "save" list for execution the next
frame.
Even then, there are significant performance and resource issues with
that kind of programming. Right now, polling in a timer is probably
your best bet.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] speed-with-pitch
På Tue, 21 Sep 2004 12:02:34 -0500, skrev David Culp <[EMAIL PROTECTED]>: > I would suggest to use airspeed as input to a PID controller, your > desired airspeed as reference and the elevator control surface as output. > I haven't tried this, so good luck! Works like a charm :-) I got it stable with: Kp=0.0125, Ti=30.0, Td=0.0 with the Piper. You can start from there, and I'm sure that fine tuning will get better performance. Thanks Roy, it works better now, but still not enough to prevent crashing. It looks like I'll still need an external monitor to clamp the pitch angle. For instance, if I'm doing an idle descent at 250 kts and reset the speed to 300, I need to keep the airplane from going straight down. 50 kts is quite a large change in reference, if you could change it gradually from 250 to 300, I'm sure that would be safer. It is not uncommon, in the process control world, to only let the reference change as a ramp. A gradual change at some appropriate rate, instead of a sudden change. If you feel that you absolutely have to control the pitch angle, I would suggest that you go for a cascade configuration. One controller to control pitch angle using the elevator and one to control airspeed using the (controlled) pitch angle. Now you can easily limit the pitch angle. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems Compiling with Cygwin again
HI! Thx that helped, now it works. :) Vivian Meazza wrote: Have you downloaded and installed openal_cyg.tgz from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ It still seems to be required for Cygwin. The error with test openal_test2.exe or something like it was present in an earlier version of simgear. Have you definitely downloaded the latest version of Simgear? FGFS does compile under Cygwin - I did it this morning. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Cu, Floh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fw: Voice stuff (sans attached)
On Tue, 21 Sep 2004 19:13:21 +0100, Giles wrote in message <[EMAIL PROTECTED]>: > http://homepages.westminster.org.uk/giles.robertson/fgfsvoice.htm ..yes??? An autorization dialog and a 401.3 off a wintendo server? > Giles Robertson > -Original Message- > From: Arnt Karlsen [mailto:[EMAIL PROTECTED] > Sent: 21 September 2004 18:52 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Fw: Voice stuff (sans attached) > > On Tue, 21 Sep 2004 09:58:30 -0700, John wrote in message > <[EMAIL PROTECTED]>: > > > FYI > > > > if anyone wants the files (about 200k) give a holler > > ..yhooo! ;-) > > > you can run the whole mess on a single machine along with FG. The > > hit to the frame rate is TBD. > -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] View for a down facing camera
I'm trying to create a new view which is supposed to be a camera fixed under the Cesna at the body. So far it looks like this: Camera View false true 0 0.2f 0 -1 0 So far so good... now I'm trying to change the pitch and heading defaults of that camera. I've tried and but none of those seems to have any effect... What am I doing wrong? Birger ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
