>No. It doesn't matter how many CPUs or cores you have if the>process can't be suspended by the main application.But then wait a minute, there's something I don't understand? As above you mentioned that it is feasable to run the ATC on a seperate computer, as long as it is "not involved in the render loop". How is this different than utilizing a seperate "core"?Thank you in advance

Why don't you just leave the build-in ATC alone and try flying in the real enviroment of VATSIM or IVAO etc. ??It's much more realistic talking to REAL people while flying.And you will be able to request a specific approach, see dual runway operations, and all the rest requested from time to time as features of the build-in ATC.The FS ATC is a good addition for some, but once you try the realism of online flying you will never ever use it again.Just my 0.02...George DorkofikisAthens, Hellashttp://online.vatsimindicators.net/811520/1704.png

>>>No. It doesn't matter how many CPUs or cores you have if the>>process can't be suspended by the main application.>>>But then wait a minute, there's something I don't understand?>As above you mentioned that it is feasable to run the ATC on a>seperate computer, as long as it is "not involved in the>render loop". How is this different than utilizing a seperate>"core"?>>Thank you in advanceTo put it metaphorically, you can't leave on your road trip until you've loaded all the luggage, regardless of how many cars you have. Ok, never mind, that doesn't actually make any sense.What we are talking about is the difference between things built into the program and things running separately from the program (i.e., other programs). Regardless of how many cores you have, you still have this main render loop trying to run as smoothly as possible, and you still have a very CPU-intensive process of real-time voice recognition (not to mention analysis, because some people will insist on being able to say "November Eight Six" and other people will insist on being able to say "November Thirty-Three Eighty-Six" and the program would have to be able to figure out that they are really saying the same thing) and even if you have a separate core dedicated to nothing else, it still might lag even the slightest bit and if it is tied to the render loop, which tdragger says it is, then we get stutters.If the processing and analysis of the vocal input is run completely on a different computer, and all that is sent back are keystrokes or even commands to instruct the ATC to do stuff, then it can take all the time it wants to, because on the computer running FS, it is just as if you had never pressed a button in response to the ATC, and the window is just sitting there waiting for you to do something. Therefore, the render loop continues looping, and the ATC is just sitting in "wait mode" until it gets an input, and the whole procedure of voice processing is done on a whole different computer. Personally, at first thought, I was curious as to why the ATC that talks to us is tied into the render loop outside of the box appearing, but then I thought about AI and that being tied into ATC and there's a lot about the connections there that I don't understand, so if tdragger says so, then I'll believe him.What I don't believe is that anywhere near a majority of flight simulator customers have more than one computer. I mean, sure, my mom has two, but one of them was built in 1991.

>Why don't you just leave the build-in ATC alone and try>flying in the real enviroment of VATSIM or IVAO etc. ??>>It's much more realistic talking to REAL people while flying.>And you will be able to request a specific approach, see dual>runway operations, and all the rest requested from time to>time as features of the build-in ATC.>>The FS ATC is a good addition for some, but once you try the>realism of online flying you will never ever use it again.>>Just my 0.02...>George Dorkofikis>Athens, Hellas>http://online.vatsimindicators.net/811520/1704.png>Oh, trust me, I've read about plenty of people here who went on VATSIM and ran as quickly as they could back to AI ATC.The main thing I read is a lack of coverage especially in less popular areas.

>Oh, trust me, I've read about plenty of people here who went on VATSIM and ran as quickly as they could back to AI ATC.>The main thing I read is a lack of coverage especially in less popular areas.Oh yes, unfortunately this is true. But it depends on lots of factors which are way out of topic for this thread.George DorkofikisAthens, Hellashttp://online.vatsimindicators.net/811520/1704.png

<<>OK: PP-ASEL Instrument Airplane (in real life). :-)<<>>Agreed.CheersRich

George, please disregard my earlier reply. I misread who you were replying to.Rich

PPASEL here too. My issue is generally that Live atc is too inflexible for my needs- pausing a flight all day due to work :) Honeydo's etc.Default ATC is always there and it controls ai as well. It's far from perfect. (38 mile final calls?, being vectored over KBHM to land at KATL?) But it is OK.Tim

>>It's not coming from microsoft ;)>>>http://www.pcworld.com/article/id,126613/article.html>>Sorry, but that's actually true.Sorry clicked the wrong reply box, I wasn't referring to your video. I was commenting on the fact that the voice recognization is going to be a 3rd party venture.

>Why don't you just leave the build-in ATC alone and try>flying in the real enviroment of VATSIM or IVAO etc. ??George,Unfortunately, I just can't 'leave it alone' !! :)As the title of this thread says, for me, it is all about making advancements and taking advantage of the emerging technologies. I have been following the microsoft research group for a couple of years and I know that group spent years developing the SR engine as we see finally bundled into XP. So, I thought ATC is the best place to showcase and take advantage of this work by another group in MS. I love FS9 and like to see it pushing the boundaries. I am totally aware of VATSIM and fully agree with you that speech recognition may never be able to replace the rich experience of real human interaction. And as the other poster stated and you concurred, I do think many people still use simulated ATC (either default one or RC) for several different reasons..Yes, I am aware of VoxATC too..not sure it runs on the remote machine though. Also, I saw many not very encouraging comments about it.. But hey, I can write my own software as I want it and share it with anyone who is interested..I see nothing wrong with that. thankssrini

>>Two words - dual core. Is this an area where dual core>>systems could provide a significant benefit in FSX?>Taildragger responded with:>No. It doesn't matter how many CPUs or cores you have if the>process can't be suspended by the main application.Ok, this one is right up the alley of one of my projects. I don't want to let on too much but, at the same time, I think I need to chime in and ask a Q or two of my own:1) It's my understanding that SAPI 5.1 / 5.3 could run SR in command mode with a set grammar, in a multitasked environment, without bogging down the other apps. Now, for those who have worked with SAPI, you know what I mean when I say that enabling dictation mode SR (which uses a 60,000+ word vocabulary that has to be checked) is out of the question since it would fight for every spare CPU cycle, just as FS does. However, I was under the impression that SR for a specific grammar command set, since it's limited to the dataset specified by the developer, wouldn't be so hard on resources. Have I got the idea correct or did I miss something?2) You could either run your SR and TTS app as a seperate app or as a dll that's called in by your app (IE: a gauge). What I'm wondering is, if it's a seperate process, then why wouldn't it be given it's own resource budget by the OS just like any other process? On a dual core system this could mean a seperate thread running in parallel with FSX... on a single core system it should work the same as running any other program in parallel with FSX, like Teamspeak. Phenome regognition is measured in Khz at worst, leaving a LOT of CPU cycles in between samples (your sample rate) that could be budgeted to other processes like FSX. Also, limiting the grammar to no more than a hundred commands at a time, by designing context sensitive grammars that are seperate datasets to be loaded or unloaded depending on the conditions, would keep the compare functions from becoming resource hogs (if there are no more than 100 possible answers at any given time then it's a lot less resource intensive than trying to recognize which of 60,000 words was the one you just said).In a nutshell, if I'm designing with 6 or 7 grammars of 100 commands or less each and taking samples at 22khz, or even 44khz, the SAPI based process should never need enough resources that it would be in the way of FSX... so what am I missing here TD?This is at the core of a program I'm actively developing right now.... if I missed something, please say so to prevent me from investing weeks into something that has a bear trap in it that I missed!Thanks,Scott / Vorlin

Hi, Scott.There is a utility that is very similar. Look for "SpeechBuddy2" in the Library. TV