Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

foxster

35
Posts
21
Followers
A member registered Sep 07, 2021 · View creator page →

Creator of

Recent community posts

(1 edit)

I'll look into it to see if there is a timing issue or something going on.

One thing to consider is it may be sending the keypresses too quickly causing one or two not to register.   You can test that by setting a value for Key Delay under the library settings (cog wheel icon to the right of the library name in the upper left).  Set it to a value of something like 10 or 20 ms and see if that helps.

It can/does handle long phrases but there are some things to watch out for, particularly with a phrase as long as the one you show. First, watch out for pauses that trigger a stop in the speech processing (particularly at 'Good day'). Speech processing processes one phrase at a time so if it is split into 2, then each one processes independently.  This leads into the second issue - FoxVox works by a command word followed by special key words.  In the default library the phrase must start with "Ground" to activate the Ground command group, then include the word taxi (and not include "back" or "ramp").  From your example, you would have to add "Gunsan" to the ground command group to be successful or make "Ground" a wildcard by adding an asterisk "*" behind it (meaning it doesn't have to be the first word spoken and can come anywhere in the phrase).  Making it a wildcard would have negative repercussions however as "Ground" is used in other key phrases for wingman, i.e. "Two, datalink ground target" or "Two, weapons free air to ground".  These commands wouldn't be executed properly because the ATC Ground command group would be activated instead of the Wingman group due to the wildcard and its earlier position in the list.  I may do a revision to prioritize keywords found at the beginning of the phrase over wildcards first, but currently that's not how it works.

So from this, you need to be sure that the processed phrase is found.  I experimented with your wording a bit and found that adding both "Taxi*" and "Departure*" as wildcards to the ATC Ground command group seemed to work best.  I also added "Departure" as an optional word on the Request Taxi command and as a blocked word to the Request Taxi Back to Ramp command to help prevent an accidental misfire. Doing this seemed to give the best results regardless of pauses being present or not.  I just had to focus on making sure "Taxi" and/or "Departure" was understood properly. Also, remember when testing and troubleshooting, be sure to enable the enhanced log to see what is being tracked as you speak.  I also think I can possibly make some enhancements with really long phrases that might help in the underlying engine...I'll experiment more for the next update.

I need to see about opening a channel on discord - good suggestion.  There's not many people using FoxVox currently, but who knows, might be more in the future.

Thanks, and yes, that's a good suggestion since things have become a bit more sophisticated than just voice recognition.  On my todo list.

(1 edit)

Just to confirm, you can switch between voice and key configurations at the upper left (just below the library name) and you must enable key recognition as shown here:

Just so you are aware, voice commands can only be triggered by voice, however key commands will trigger based on not only key input but also trigger on conditions, which is why they reside there for the VCC.  If you have enabled key commands and everything is triggering but you still don't hear anything, check to see if you have windows media player installed or disabled.  They will also play if an alternative player has been set up in Windows, but you may experience issues there if they can't open through the Windows shell command.

Edit:  Also make sure the VCC files which contain the audio files are present in the subfolder with the library...sometimes it's the little things that can get overlooked.

Let me know if the latest v2.4.0.2 makes any difference.  Hopefully it helps!

Hi there, glad to see your desire to be creative with the app.  I'm not sure how well it will function for how you intend to use it, but certainly give it a try.  As for the error you report, this is a strange one.  The app is basically saying it is failing to find any qualified speech recognition modules on your system.  What language is your Windows installed with?  Can you check if there are any sub folders found in the following location:

Windows install path (default C:)\Windows\Speech\Engines\SR

For default English US for example there will be a folder call 'en-US'.

If you are finding at least one folder there, the issue may be due to a permissions error in the MS System.Speech module accessing the registry.  In that case, installing the app with the installer and possibly running it as an administrator could potentially solve the issue.  If there aren't any, then you don't have any recognition engines installed and you'll need to install one here:

Select the Start  button, then select Settings  > Time & Language > Speech

Please be aware:

  • Speech Recognition is available only for the following languages: English (United States, United Kingdom, Canada, India, and Australia), French, German, Japanese, Mandarin (Chinese Simplified and Chinese Traditional), and Spanish.

There are new languages supported using the MS Speech Platform 11 but FoxVox does not have those implemented currently.

I will add in some additional error handling to detect this issue more gracefully, but see if you can investigate what I suggested to try and solve it.

Really strange, but glad it's working.  I run neither as administrator and they work fine.  Perhaps your BMS installed in a protected location like 'Program Files'?

Ok, that is helpful information and I will take a look into performance with the next upcoming release.

Interesting.  The key recognition disabled rules out output overload.  Are you running any virpil control software at the same time?  Without key recognition running FoxVox is only passively monitoring input which shouldn't cause any lag.

This sounds like an issue with output overload which happens when every tiny movement of the analog stick causes the output to fire, which can quickly overwhelm the system.  If you remove/disable the slider binding does everything else work OK?  It would be good to narrow down the culprit.  Also, just to check, does the system bog down or have any problem when you move the axis while the Key Recognition is disabled (keyboard button second to last in the toolbar)?

I'll look into it. Can you explain how you are settling it up so I can duplicate it? 

Welcome back to BMS...glad you like the app!  One thing that comes to mind is make sure that in the settings (little cog wheel icon by library name) you allow any process (by not having any assigned) or include it in the allowed process list.  I'm not sure this is the issue though, as you say the built in ones are working.  Make sure the command window shows that the voice command is being activated/recognized, and make sure the outputs are defined properly.  If you can detail a specific question, I'll be glad to help either here or in the BMS forum.

Regards, Foxster

Thanks Mistral.  I must confess, these have been resolved already and are part of the next release, but it's been slow in coming due to the intricate and complex addition of supporting variables on inputs.  This is part of the next phase to prepare for full dynamic integration with BMS (and potentially other apps).  In the future, hopefully by BMS v4.38, FoxVox will automatically utilize callsigns, detect which seats are human vs AI, automatically set PTT to match UHF and VHF assigned buttons, and use direct callbacks rather than menu assignments for all comms.  It will also auto-bind brakes, flight controls, and buttons used by the Virtual Crew Chief which are set in BMS.  There's a lot of work going into this and all of it will make FoxVox more versatile in the end.  In the meantime, thank you for pointing out these issues - please continue to do so, and thanks for your patience.  Look for the next update releasing soon!

This is already underway...and where it's headed soon.  The library will automatically integrate with BMS bindings, call signs, etc.

I'm looking into this further, but for now make sure that the Windows speech recognition is set to match the same language selected in FoxVox, and also make sure the Windows UI is set to the same language also.

I will be fixing/improving this area soon as other's have reported the same issue and it really shouldn't be as quirky as it is.

Try the new update and see if it fixes your issue. 

Well, I think the cross section of users is pretty small, so you alone probably make up a fair portion.  It's not hard to add and won't compromise existing functionality, so I suppose I'll do it.  I'm sure you won't be the only one with the issue.  Glad you found and fixed it.  If you like the app, be sure to pick up the next version coming out soon.

Good to know - thanks for sharing your issue here. When you play a sound from an output command, you have the option of disabling the internal (wmp) player and have it play with through the associated shell extension which would in your case launch vlc and play it that way. The downside is it needs to launch the app through the Windows shell (meaning the file extension must be associated in Windows with vlc).  Unfortunately this is currently only available on sounds played through an output. Based on your feedback I'm considering adding a global setting that will disable wmp and play all sounds through the Windows shell. I could also have it detect and set it automatically if wmp is not installed on the system.  This might fix your situation...any thoughts?

Ah, yes, it does rely on media player in some cases. It didn't originally but I revised it to support other media types besides wav.

Yes wav files are fine, as are other formats.  What you're doing should work fine.  If you're using headphones be sure other computer sounds aren't muted and are coming through...just to be sure it's not something simple overlooked.  I've never had anyone else report this so far and it works fine for me.  Very unusual.

Hmmm, shouldn't require admin rights or anything special.  Are you setting it to play on key recognition or using an output with a play file in it?  I'll run some tests before launching the next update (very soon & it's a good one).

Ok, I've posted an update to attempt to fix the issue.  Unfortunately I don't have any hardware to test, so I'm relying on you to let me know if it resolves the issue.  Also, I've added in a feature with the Push-to-Talk settings that let you specify 'Any Key' to allow any of the bound keys to activate PTT rather than all.   Let me know how it goes!

Make sure that the button isn't registered in the block list (found in settings).  Otherwise, FoxVox won't pick it up when it is pressed.   Some other settings in the PTT could also affect it such as the 'Isolate' option which limits PTT to not work if any additional keys are pressed besides the bound PTT Keys.

Besides this, what you describe doesn't seem to be a FoxVox issue.  As you said, it picked it up when you assigned it to the PTT.  Make sure the hardware/drivers are passing through the button accurately and consistently on press each time - FoxVox doesn't do anything with the input besides monitoring the button states passed in by the OS.  Verify it's not being affected by any controller macro logic or third party apps.

I've considered adding more ptt options but haven't really needed it yet.  I have element and other team comms bound to vhf and atc/ground commands bound to uhf.  I'll consider more options for the future.

Hmmm.  Are you binding both buttons to the same command in the PTT?   If so, then both buttons would be required to be pressed together - at least how the program works currently.   If you try using just one (either UHF or VHF) as a test, does it work consistently?  If so I may need to add support on the PTT to allow for either AND/OR condition for multiple buttons.  In its current state ALL defined PTT buttons must be engaged together at the same time - it's not an either or.

Aside from this, you could test if there's a joystick detection problem by testing with a keyboard key instead and seeing if it works consistently.  You should see the PTT engage and disengage by the icon turning green whenever the button is pressed.  Try testing with some simple scenarios and we'll go from there.

Let me know what you find.

Right now spell is limited to alphanumeric only.  I'll give it some thought though.  At least we got the numbers sorted out.

Ok, let's see if it's resolved now.  I provided a little more info in the changelog you should review.  Give it a go and let me know the results.

You have uncovered a rather unusual little nuance in the recognition here.  I will post an update today that will address it.

(1 edit)

Hi @Wreckluse,

First, posting questions and comments here is perfectly fine, and I'll do what I can to answer.

With regards to the delay, this probably has to do with the microphone/sound detection changing between VR and non-VR/normal operation.  Are you perhaps using a different microphone setup when you play VR vs standard?  The delay is usually caused because the active microphone is picking up external sounds still even after speaking is completed.  The speech engine remains listening without letting FoxVox process the speech until it finally times out.  You can visually see this if the listening indicator icon remains green for some time after speaking.   To fix this, try reducing the sensitivity of the microphone, keep it away from computer fan noise and any other sources of sound that it might pick up as background noise.  You can also play with the Timeout setting in FoxVox by entering a low value (like 1) to try and force a timeout earlier.

For your question about numbered commands, I recommend you always use spelled out numbers for the voice command keys (i.e. "One", "Two", etc.) This will prevent "One" from conflicting with "Ten". If you run into a conflict  such as "One" vs. "One Hundred", you will need to put a blocking word of "Hundred" onto the "One" key so that it can tell the difference.  Alternatively you could place the "One Hundred" command above the "One" command so it will be evaluated first and will be skipped if "Hundred" is not contained in the spoken phrase.

Thanks for your positive comments about the app and I'm glad you like it!  My hope is that it can be a useful tool for anyone needing free and customizable voice control :)

Awesome, glad to hear it!  If you'd like me to post your library here for other DCS users once it's ready, just let me know.  I'm sure others would benefit from not having to start from scratch.

Depending on the game, you may need to add pauses (between 10-50 ms typical range) on or between key events to get them to register.  Otherwise they are so fast that the game might not register them.  You may want to experiment with this.  I show how to do this with mouse outputs in the last chapter of my basic tutorial video with drag-drop (it works the same for keyboard outputs).

In the settings menu go into the "Block Inputs" and add all those buttons that are flooding the detection.  They will then be ignored by FoxVox. You can then set the PTT.  Alternatively you can just delete them from the PTT after capturing them along with the button you want.

Yes, just enable the 'Inverse' option when you define the PTT and it will change to push-to-mute.

Ok posted here. Thanks!

Danaos, that's great! Much appreciated. Do you have a file share like Google docs where I can get it? Otherwise I'll set something up for you to post via PM in the bms forums.