You may need to turn speakup off temporarily do the dectalk keystrokes then turn speakup on again for your results. If keystrokes and their destination got stored in a script running the script as speakup is off then enabling speakup ought to be more certain to work. Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) . On Mon, 19 Sep 2022, Chime Hart wrote: > Hi All: I think I remember in Vocal-Eyes, we could hit a control+n to send > commands directly to a synthesizer. Does Speakup have such a way? Reason I > ask, on the DecTalk discussion list, we've been discussing my long-standing > Speakup related sudden changes in pitch, rate, and volume. And so this > question came up about a bipass. To continue, here are Don's comments from > earlier today > The problem is that we can't talk to the DECtalk without going through > SpeakUp. To test the condition you pose, we could tell DECtalk to use > some other voice. Then, after the "drop" happens, see if it has reset > the parameters of THAT voice... or, changed to the voice that SpeakUp > *thought* was being used. > > We also don't know what the values are reverting to. Or, what their > various defaults might be (power up, nonvolatile memory, speakup settings, > etc.) > > For an original DECtalk, we could enable logging and just look at the > characters that were being sent to the DECtalk by SpeakUp. If there > are no control sequences that try to alter these settings, then we > would KNOW that it was something that was happening inside the DECtalk > unit. > If, on the other hand, we see some commands being sent but they are > incorrect, then we know the problem lies in SpeakUp. > I don't know how to divorce the serial interface from SpeakUp so that > we can eavesdrop on it. There are some ways to do this but I don't > know how they will color the results. > The better solution would be if SpeakUp had a debug mode that caused > all output to be copied to some log file that could be analyzed after > a "drop" was noticed. You could then manually examine the log and > identify whether SpeakUp was causing a parameter change or not. > This would also help the developers backtrace to see why the commands > were being issued and why they weren't correct. > Chime > >
