I have just tried out the three voice recognition systems I know of ("VoxATC", "It's Your Plane" and "Multi Crew Experience") and am very frustrated with what I have seen. VoxATC is very buggy and the other two doesn't offer an ATC experience beyond what FSX can offer by default. Also, even if VoxATC had worked (I couldn't complete a single flight during the trial), it would still be a bore compared to RC because of it's lack of diversity in voices: There's just five synthetic voices (male/female controller, male/female AI pilots and a second officer). Also, as a voice recognition package it's very rigid: You need to say the exact phrases expected by VoxATC or it won't "hear" you.The other two packages offer a better a voice recognition experience as they allow for variations in phrasing without ignoring you. However, they don't support ATC by themselves, like VoxATC and Radar Contact. Instead they sit as an interface between the user and the default FSX ATC which is a good idea (too much integration is usually a bad thing). Actually, "It's Your Plane" claims it offers such an interface to Radar Contact which I feel is a very promising concept. However, I couldn't really see any other options than being able to say "press 1" or "press 7" etc. That's not really what you want to way to ATC so...If someone where to head out and write a voice recognition interface for interface Radar Contact he/she would need to capture the output (binary/text) from RC. This would be required in order to validate the user's voice input and decide whether it is correct before it can interact with RC.Would such a piece of software be able to capture the RC output? If so, where could I find information about that?Cheers/Jonas

Actually, "It's Your Plane" claims it offers such an interface to Radar Contact which I feel is a very promising concept. However, I couldn't really see any other options than being able to say "press 1" or "press 7" etc. That's not really what you want to way to ATC so...

You seem to be missing something there. IYP provides a host of different, more realistic, ways of expressing your responses to RC. Yes, those end up sending a Control +Shift + 1 or 2 or 3 or whatever -- the relevant keys which RC recognises -- but those are generated invisibly. You simply say more or less what you might be expected to say in the circumstances.It sounds like you only looked at the very first section of the command list, the one which does allow you to say "Select N" to specifically select a menu item. But those are just "catch alls" in case you forget the right phrases.I append below the current set of spoken RC commands -- I've just "lifted" these from the RC commands list on the IYP website. (It's "Key 1" etc means "Ctrl + Shift + 1" again now -- it has been changed twice).RegardsPete=========================Main menu ----- Emits Key 0Acknowledge and contactAffirmChoose landing modeContact approachContact controlContact deliveryContact departureContact groundReady for departureContact towerMonitor towerRequest taxi ----- Emits Key 1 Abort take offReject take offFlight critiqueGet A T I SMissed aproachLeave frequency for weatherRequest departure runwayRequest runway for departureRequest weatherRequest push and start ----- Emits Key 2 Contact ground for clearanceEnd radar contactGet clearance ----- Emits Key 3 Clearance by F F SRequest higherRequest I A P approach ----- Emits Key 4 Contact ground for push and startRequest landing runwayRequest lowerRequest runway for landing ----- Emits Key 5 Unable to comply ----- Emits Key 6 AcknowledgeCleared for take offCleared to landLine up and waitOver to next controlTaxi to the rampTraffic in sight ----- Emits Key 7 Previous menu ----- Emits Key 8 Next menu ----- Emits Key 9 Display flight plan ----- Emits CTRL+SHIFT+P Repeat Last Instruction ----- Emits CTRL+SHIFT+R Save radar contact ----- Emits CTRL+SHIFT+; Set nav frequencies ----- Emits CTRL+SHIFT+L Take over communications ----- Emits CTRL+SHIFT+K Take over plane ----- Emits CTRL+SHIFT+M ===============================

You seem to be missing something there. IYP provides a host of different, more realistic, ways of expressing your responses to RC. Yes, those end up sending a Control +Shift + 1 or 2 or 3 or whatever -- the relevant keys which RC recognises -- but those are generated invisibly. You simply say more or less what you might be expected to say in the circumstances....

Indeed, I had missed the more elaborate phrases. But even with those it is still a matter of one-way communication where the user tells RC which option should be selected at the moment. I would like an interface that expected proper read-backs based on what RC had told the user to do (like with IFR/approach clearances) and for that the voice interface needs to be able to intercept and parse the RC output. Is that possible and, if so, how?/Jonas

I would like an interface that expected proper read-backs based on what RC had told the user to do (like with IFR/approach clearances) and for that the voice interface needs to be able to intercept and parse the RC output. Is that possible and, if so, how?

It is "almost" possible. You could have a program interface to FSUIPC and monitor the 128-byte field in the offsets where RC writes its menus for display.However, sometimes the options available spread over more than one batch of 128-bytes -- this is where RC has next/prev options for the menus. List of runways or altitudes, for example. There are others, but I think those tend to be for standard things like declaring emergencies.So, thinking aloud here ...Maybe, if I offered JD more offsets in FSUIPC, he could be persuaded in Version 5 to provide a more programmer-oriented menu interface (as well as the current one, of course). For instance, if there are, say, 64 different possible options, then two 64-bit fields, with a bit for each in the first with a '1' indicating that option is now available, and a bit for each in the second for another program to make the selection. The bits would have documented pre-defined meanings. There would need to be many more bits than current options need in order to allow future expansion, etc.Of course, with runway lists and altitude lists that wouldn't be quite right, so one of the bit positions would be for runway list, and that list would have to be given separately. Same for altitudes. Plus a selection mechanism for them -- probably by writing a list entry number into a response byte.I'd be quite happy to help JD work something out like that, but I suspect there are currently more pressing matters for him in Version 5's development. Something for the "want list" maybe?RegardsPete

...I'd be quite happy to help JD work something out like that, but I suspect there are currently more pressing matters for him in Version 5's development. Something for the "want list" maybe?...

Yes, maybe. I'm a developer but I would think twice before I committed myself to write such an interface, at least for the time being (I have fairly small kids that needs a father :( ). Just wanted to see if it was theoretically possible. As the possibility doesn't exist anyway at the moment wouldn't it be even simpler to provide output without using FSUIPC, say through a TCP port? Btw, is there information anywhere on what to expect in RC5?Cheers/Jonas

As the possibility doesn't exist anyway at the moment wouldn't it be even simpler to provide output without using FSUIPC, say through a TCP port?

Why do you think that is simpler? RC already has an interface to FSUIPC. It is much easier to provide interaction that way. I would have thought adding new networking code would be a lot more extra work, and an interface protocol would need designing either way.In the end it would be up to JD, when and if such an item rose to the top of his long long list. ;-)RegardsPete

Why do you think that is simpler? RC already has an interface to FSUIPC. It is much easier to provide interaction that way. I would have thought adding new networking code would be a lot more extra work, and an interface protocol would need designing either way....

Guess there's a point in what you say. :( Regards/Jonas

Feel free to interact in this thread (FSX forum) as well and help us get over misunderstandings or ignorance:http://forums1.avsim.net/index.php?showtop...p;#entry1621885Thanks /Jonas

I have just tried out the three voice recognition systems I know of ("VoxATC", "It's Your Plane" and "Multi Crew Experience") and am very frustrated with what I have seen. VoxATC is very buggy and the other two doesn't offer an ATC experience beyond what FSX can offer by default. Also, even if VoxATC had worked (I couldn't complete a single flight during the trial), it would still be a bore compared to RC because of it's lack of diversity in voices: There's just five synthetic voices (male/female controller, male/female AI pilots and a second officer). Also, as a voice recognition package it's very rigid: You need to say the exact phrases expected by VoxATC or it won't "hear" you.The other two packages offer a better a voice recognition experience as they allow for variations in phrasing without ignoring you. However, they don't support ATC by themselves, like VoxATC and Radar Contact. Instead they sit as an interface between the user and the default FSX ATC which is a good idea (too much integration is usually a bad thing). Actually, "It's Your Plane" claims it offers such an interface to Radar Contact which I feel is a very promising concept. However, I couldn't really see any other options than being able to say "press 1" or "press 7" etc. That's not really what you want to way to ATC so...If someone where to head out and write a voice recognition interface for interface Radar Contact he/she would need to capture the output (binary/text) from RC. This would be required in order to validate the user's voice input and decide whether it is correct before it can interact with RC.Would such a piece of software be able to capture the RC output? If so, where could I find information about that?Cheers/Jonas

Moggel, have you tried the latest version of "Multi Crew Experience"?It does interact with RC4 quite well.

Gerald Reilly