On Wed, Sep 30, 2009 at 03:43:32PM -0500, Adam Myrow wrote: > On Wed, 30 Sep 2009, William Hubbs wrote: > > I guess what I'm wondering is, since pitch shifting isn't supported by the > > dectalks, I'm not sure that messing with the pitch for caps indication > > as the default is a good idea. What do you think? > > I don't know, but every other screen reader in existence has made this > work for well over a decade. Most screen readers do the pitch shift by > default, and will offer another choice of saying "cap." In other words, > they don't have hard-coded strings. I think that this is the way Speakup > should go. Another way to see this is these other screen readers offer you hard coded choices for what to do with caps -- Hearing a message, pitch shifting, or nothing. Speakup, on the other hand, lets you send anything you want to send to the synthesizer for caps indication. This could be any text such as "cap, ", "upper case, " or any synthesizer command you want before or after the caps. I'm trying to avoid locking users into either a pitch shift or a message. I feel that allowing the user to define exactly what happens in this case is more flexable. > There would be a parameter to either say something, or shift > pitch. > If the user set the parameter to say something, the string could > be a message that could be in with the other i18n messages. For pitch > shift, just do the math. For example, the current pitch is 100, so add > 50, then send the command to the synthesizer to set the pitch to the > result. When switching back to lowercase, just send the command to > restore the pitch to what it was before. To me, this kind of setting would limit the user; see my comment above about the other screen readers limiting your choices of how to handle caps. The other thing I'm concerned about with this idea is what is going on now -- our notion of the current pitch can be wrong with the dectalk, since it changes the current pitch with the voice you are using, and doesn't offer any way to query current status that I have found so far. > Another thing to consider is > that some screen readers, like JFW, let the user determine for themselves > how much of a pitch shift there should be for uppercase letters. In the current situation, if a synthesizer supports pitch shifting, which several do, we have this covered. With the dtlk, ltlk, software synthesizers, and I think there is another but I can't name it right now, the synthesizer supports pitch shifting directly, so the default commands for them are set up to use relative pitch adjustments. If you want to increase or decrease the adjustments you just have to redefine the commands. Let me know what you think. William
