The first problem we need to solve is to get the menu talking while raspbivoice is running.
I hope you just mean the menu for raspivoice, and not the main menu that launches the programs.
If you want to hear what happens when you make the main menu stop being quiet it's actually quite easy. Go into the python code for menu.py and comment out every line that contains the bequiet variable.
You will find that although you can now operate the main menu, the menu within raspivoice is also activated. when you rotate to the right, you will hear both options walking over each other.
This unfortunately makes the job into three possibilities:
1. move all menu commands from raspivoice to the main menu, and relaunch raspivoice with each change by passing command line options ( I don't see this as too bad of an idea, as it also lets the other options get added to the config file if we so choose). raspivoice launches quickly, so it doesnt introduce performance degradation.
2. move everything into cpp. I'm against the second option because then I can't really participate. I do recognize that it gives performance advantages, but I don't feel like the menuing system in python is overly taxing, and I find it's very easy to understand.
3. This may sound weird to understand, but I think this is actually a really good idea, and uses more python so I can help. Remove all rotary encoder options from the raspivoice cpp code. migrate all the functions to menu.py. Once you have launched programs, the menu level can change to an 'operating menu' where the functions currently in raspivoice can be migrated, but we can also add the option to toggle teradeep, toggle raspivoice, toggle distance readout, and toggle vibration, or killall running programs and return to the main menu.
I strongly favour option 3.
I also want to let Peter know: I've heard your complaint about keyboard input being required, and I will put something in my next revision. I had been planning on arrow keys and the space bar. I just had a thought though. I was considering a number pad. This would be convenient because there are lots of cheap usb number pads (a quick ebay search found some for $7). This could act like a replacement for the rotary encoder for those people without the physical hardware I have been providing. This also opens up the possibility that more people will use and contribute to the software, or fork it for their own specialized needs.
Consider the following: The software stack where it is, any UVC camera (I didn't get the $2 ones sadly), rpi v2 $35, usb keypad(7$), rpi case ($10), and 10,000 mah external battery ($40). This lets people make compatible devices for minimal costs (<$100) as I had always intended, and they can do it out of mass production.
Obviously this adds even more wires to the mix, and removes the rangefinder. I already get complaints about the wires, but that price is absolutely amazing.
I don't think I can do it for a few days as I have my hands full with travel and kids, but maybe by the time that is done, mr. indoj will have a new image up, and I can add that in along with the spoken distance option. I also cleaned up a few other things where espeak was walking over itself on startup, and added a few contextual speech cues that were missing (ie. when you launch raspivoice and teradeep, it now says that rather than just launching without saying. That way the lag on teradeep startup is less worrisome.
So you can expect that fix in the next few weeks.
If you want to help out your friend in the meantime, you can provide system image files where you have changed the autolaunch settings. I would offer, but my record for getting cloud storage to work lately has been abysmal. I'm almost to the point of spending money on dropbox or something.