It only looks like you forgot to update Options.cpp with "opt.contrast = 2.0;" and "--contrast=[2.0]\t\t\tContrast enhancement factor >= 1.0" (given your choice of not supporting complete disabling of contrast enhancement, or else it is better to look at my today's pull request for the changes in KeyboardInput.cpp and Options.cpp at https://github.com/aftersight/After-Sight-Model-1/pulls
I believe there is some confusion about how we are operating raspivoice currently.
Sometime near December, the decision was made to make a background frame grabber for the camera, and then let this process distribute frames to different processes such as teradeep, raspivoice, and recently to the facial detection routine. In line with this, it was also decided that the rotary encoder input in raspivoice would be disabled, and all options that people wanted would be migrated to the main menuing system.
ie. rather than launching raspivoice, and then having the startup menu system be quiet to let raspivoice have it's own speech driven menu, we opted to turn off raspivoices speech driven menu. this allowed the main menu to continue to operate to launch the other processes at the same time.
as a result we use an intermediate launcher for raspivoice which is located in raspivoice.py. All the options for raspivoice that we currently have in the main menu->settings->raspivoice settings menu are executed as command line options. This renders the default settings in options.cpp less important. the option settings are stored in aftersight.cfg and are persistent boot to boot which is a nice behaviour.
I do agree that the updates for options.cpp and keyboardinput.cpp ought to be implemented as well, but this would be primarily for the raspivoice standalone, or for Ares repository (which I saw you already submitted to him).
in our implementation, when you change a raspivoice setting, it actually kills raspivoice, and then restarts it with the changed command line flag. This introduces a short but noticeable lag on the rpi v 2 hardware, however on the rpi v 3, that short lag is almost non-existent.
I hope this clarifies to a certain extent.