Default time delay for Delayed descriptions for characters on cursor movement is too long

[LittleStar-VIP]

Is your feature request related to a problem? Please describe.

I am testing the newly introduced function of "Delayed descriptions for characters on cursor movement" under nvda 2022.3 beta 1 and found that I have to wait a very long time before I can hear the character description of a character

Describe the solution you'd like

Well, although we already have relevant discussions in the pull request thread, I would like to put forward here, to recommend that nvda to allow user to configure the delay time of the Delayed descriptions for characters on cursor movement function.

In the pull request thread, there were discussions on to what extend the user should be allowed to configure the delay time,

1. do not give user any option to change the delay time
2. giving three options (slow, medium and fast)
3. giving the option for user to input the exact number of delay time, but there is a debate on whether the unit should be microsecond or second

Describe alternatives you've considered

https://github.com/nvaccess/nvda/issues/13915

Additional context

[TechHorseG]

Oh, is NVDA finally offering an inbuilt auto-phonetic character description on caret movement? That is great news, as I haven't updated NVDA in two years because I really didn't want to lose the functionality of the "Enhanced phonetic reading" addon (which became incompatible around two years ago).

Anyway, Just like the aforementioned addon, NVDA should IMO offer a user definable delay, and in milliseconds. Offering it in seconds only isn't going to provide enough nuance. Someone who finds 1 sec to be just a tad too short, may find that 2 seconds feels like a long time. And someone who finds 1 sec too long may find 750 ms to be the sweet spot.

IME pauses of even 250 ms longer than you'd prefer can feel a bit draggy, so I always would prefer to be able to define my preference in ms rather than having to work with whole seconds only.

But all that said, personally I was happy with Enhanced phonetic reading's default 1000 ms delay, so whatever options are offered, please include a 1000 ms / 1 s delay as that is what I am used to!

Again, great news that this feature is in the works :)

[seanbudd]

I've added #13915 as an alternative solution. We would prefer to follow that approach first to see if it resolves this issue.

[seanbudd]

What time would you prefer for default? What values do you think are appropriate for slow/medium/fast?

[LittleStar-VIP]

Currently I am using 300ms as the delay time for the enhance phonetic reading addon for me, the current default delay time could be regarded as a long one.

[TechHorseG]

@seanbudd, firstly, thank you for the link to the new Enhanced Phonetic Reading addon update you supplied on the other thred. I had no idea there was one, thanks again!

I think the fact that one user thinks 1000ms is too long and another finds it just right, suggests that people should be able to enter a custom value rather than have three prescribed options?

After all, there won't be any complaints over a custom setting, but there might be if someone doesn't get on with any of the three available preset options!

[ruifontes]

Why insisting in fixed values?

What we are asking is the possibility to set a value between 0 and 1000 mileseconds...

Rui Fontes

Às 07:51 de 04/08/2022, Sean Budd escreveu:

What time would you prefer for default? What values do you think are appropriate for slow/medium/fast?

— Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/13967#issuecomment-1204838665, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADZAPRUCFEYT6AZRSUMNHH3VXNSABANCNFSM55C6EELA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[davidacm]

Also here, in the Spanish community, some beta testers complained about the inaccurate delay for the delayed descriptions.

There are two separate cases. First, the related with the inaccurate pauses of each synthesizer, especially on sapi 5 and one core. But we've talked about this in depth in #13550. 1000 ms are not always 1000 ms and it depends on the speed rate that you are using.

second, the impossibility to adjust the delay. If the user guide says 1000 ms... But with my synth I feel it as 1500ms, or another user feels it as 500ms, because that user and I are using different rate speeds, those are mixed issues.

What is the inconvenience to let the user to set the wanted delay in numeric values? Users are not unsmarting people and all users understand the meaning of numeric values. I would say that 99.999% of users understand the meaning of seconds, milliseconds, etc. Three or four values... it Would be the same thing as if NVDA implemented slow, medium and fast for the voice rate speed, right? Users have been dealing with the voice rate in numeric values without inconvenience, during years. And if you tell the user that the value to be adjusted is in a specific measure, s/he would have an idea of the final result.

As the developer of enhanced phonetic reading, I've received many suggestions during its development since 2019, when I started with this add-on. And I noticed that there are many different situations for each user. Even the same user can have distinct needs according with the environment, or the tasks s/he is doing. When I started with it, deaf people asked me the possibility to adjust very short delays, I did it. But then, people with fine motor difficulties asked me to increase the delay limit. And that makes sense to me. Then I increased the limit to 5000 ms. That is very high for me, but maybe someone want that high delay, I can't think in all possible cases.

If I think as a deaf person, I would prefer to hear the description quickly, because I likely could confuse some letters. But if I can't press the cursor movement keys quickly, and I can understand the letters correctly most of times, I wouldn't like to hear the description every time I make a cursor movement. Unwanted information can interfere to process the information I read.

And this last case is a personal one. When I change to read another language, I like to have shorter delays than when I'm in my native language. How much delay? It depends, if I'm reading English that I know the basics, or is a language that I'm learning like Japanese. I use shortcut keys to change the profile with the wanted synth and language. I even prefer distinct delays if I'm coding or if I'm doing music editing, or if I'm writing a message like this. Currently I have the English profile enabled, and I would like to have shorter pauses than if I were writing a Spanish message (my native language).

And one thing that I like of NVDA, is that I can personalize settings exactly as I want. Or I can keep the default ones if those are not important for me.

I use synths at high rates, that is very relative but for example: I use one core voices with rate boost enabled, at 85%. Or voice over at 100%. At those rates using one core, the pause between the character and character description are too fast for me. Then, I need to disable the core feature at all. the user guide says 1 sec, but that's very far from reality in my one core synth at 85% with rate boost enabled. And not, although that could be a high rate, I don't want faster delays for character descriptions.

Because although I like high voice rate, I don't like short pauses between character and character descriptions.

I know that my add-on still can help, but many people don't know the existence of that add-on. Although this has a lot of downloads, even the latest releases.

So, the pr #13915 can add another problem for users wanting to use the delayed descriptions, added to the main issue (the inaccurate pauses of most of synthesizers).

Please try to put yourself in the place of each situation / person, and you will be able to contemplate many things that you had not thought of before. Even if you do that, you won't be able to imagine each case. But is a good practice as developers to satisfy final users, and not only technical / architectural / personal cases. Many users don't know how to contact us as developers, and is hard to know what are the feelings or needs of those users, particularly from users with foreign languages, that is a big communication barrier. Many users don't know how to speak English, or don know how to get the channels to inform about their unconformities.

E.G. Many people don't have github accounts to comment here (they're not developers / translators) and I understand them, I would not open an account just to comment something that maybe won't not be heard by the developers. So, I'm commenting this feature again.

Best regards, David CM.

[davidacm]

P.S. The user guide should clarify the behavior of the inaccurate pauses between character and character delay, and make the clarification that it depends on the synthesizer used, and the adjusted rate. Also, this clarification should be written in the "wat's new" of NVDA, because old / advanced users just read the changes including myself. And most of them don't read github comments. so, the user would be aware that the difference could be due to his synthesizer and the adjusted speed and won't complain by things that we already know.

[sergiogomez31]

Hello everyone, The truth is, there is too much delay with some synthesizers... it seems horrible to me, really. I think I'd be better off giving the user the option to enter a timeout in milliseconds, between 0 and 1000.

Cheers

[mzanm]

Yeah I don't get why against Milliseconds, it's already used in the braille settings with the cursor blink rate, so how is this different?

[TechHorseG]

@sergiogomez31, I am glad to hear that the delay will be customisable, and in ms.

My only reservation is with the upper limit being capped at 1000 ms. Others have expressed a need for a higher limit, and I would appreciate it too.

In another post I gave quite a detailed explanation as to why, for me, 1000 ms hits the delay sweetspot. See https://github.com/nvaccess/nvda/issues/13915#issuecomment-1205039902

But that is relative to my current synth / speech settings. I am concerned about the future possibility where I find a new synth too slow, and so increase the rate for it. But then this leads to the bad experiences of spell-checking described in that post, when the delay comes too soon.

In that case I would want to increase beyond my current 1000 ms setting.

From a programming perspective, is there any issue with having a max cap of 5000, or even 10000 ms?

[valiant8086]

Also if at all possible, I want to be able to stop the delay entirely, a alpha would suit me just fine and that's how people do it when calling in license plate numbers and whatnot.

 g golf, o oscar, o oscar, d delta,

Cheers: Aaron Spears, AKA Valiant8086 General Partner at Valiant Galaxy Associates "we make (VERY GOOD AUDIOGAMES) for the blind comunity" http://valiantGalaxy.com

On 8/12/2022 2:57 PM, sergiogomez31 wrote:

Hello everyone, The truth is, there is too much delay with some synthesizers... it seems horrible to me, really. I think I'd be better off giving the user the option to enter a timeout in milliseconds, between 0 and 1000.

Cheers

— Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/13967#issuecomment-1213424643, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADZNWQIV47L3V32ARBMN6BLVY2NBFANCNFSM55C6EELA. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[davidacm]

Hi, where you read that the delay will be customizable? Max limit of 1000 is not a good implementation, 1000 ms should be the default, not the max limit. And considering that depending on the synthesizer being used, where X ms could be more (or less) than the specified parameter, the value is just a reference. In my case, I use 1000 ms with IBMTTS. But when I change to one core, I would need to adjust this around 2000ms, because at the usual voice speed I use it, 1000 ms is too fast for me. In fact, I would have to change the delay value if I decrease the speed, but that issue was discussed a lot in another thread.

[Qchristensen]

Just adding one note from a thread in the user group: https://nvda.groups.io/g/nvda/message/100163

The extra delay in this feature seems to happen primarily with the Code Factory Eloquence / Vocalizer package rather than eSpeak-NG or OneCore.

[davidacm]

Hi. Editing the comment because I think I misunderstood the issue of the referenced thread. As I understanding now, the issue is that the cursor movement, even to listen the character (not the description) is slow with the feature enabled. And this issue is present on vocalizer and eloquence voices of Code Factory. I can't test it because I don't have those voices...

But, my original point is still valid, and I see some users commenting about that in the referenced thread.

Original comment:

There are two separated issues:

1. The fact that the implemented feature does not allow to the user to set a custom delay. This is important and I already commented why. It depends on the context of a task, or the condition of a specific person.
2. The break pause command is very innaccurate for one core and sapi 5 voices, changing a lot according to the current rate speed. A person with a slow rate configured could feel as a high delay. And users change the speed very often, according to the tasks they are doing.

[seanbudd]

It would be extremely helpful to have data on how much the delay changes. e.g. the delay at 0, 50 and 100 rate. It's hard to quantify the significance of the variation in delay without numbers. From what it appears, the variation is quite small, and addressing (1) as planned should hopefully alleviate the major friction.

[seanbudd]

The extra delay in this feature seems to happen primarily with the Code Factory Eloquence / Vocalizer package rather than eSpeak-NG or OneCore. Hi. This issue is present on One core and sapi 5 voices too.

@davidacm In case you misread, this thread is referring to NVDA lagging in general while this feature is activated with Eloquence, not the delayed character itself being too long.

[davidacm]

Hi @seanbudd, the variation using Espeak is small although is still noticeable. But is not the same situation with sapi 5 or one core voices, with those engines the variation is very high. I could do those measurements, recording the audios and analyzing them on an audio editor and then, report the results here, with the recorded audios as reference. But that would take time... And I think that even so, I think you wouldn't act on it even with the evidence. I and other users presented several arguments about this topic. So, I don't know if the effort would be worth it.

P.S. I edited mi previous comment, because I read the referenced message very quickly.

[seanbudd]

even an estimate would be helpful - e.g. 0.5-1.5s variation from 1 second

[CyrilleB79]

@seanbudd the difference of delay is quite obvious even without measurement. I have done a quick audio-only test with OneCore Zira with an online metronome set to 120bpm in background. The following sets of parameters give the following results:

• rate = 100%, rate boost on: delay < 0.5 sec since delay between keypress and speaking "alpha" (including speaking "a" and pause) is about 0.5 sec
• rate = 5%, rate boost off: delay is about 2 seconds, i.e. 4 ticks between the end of speaking "a" and the beginning of speaking "alpha".

[seanbudd]

Thanks @CyrilleB79 , that description is really helpful. We may have to change how the break command is implemented, so it works consistently at different rates. I imagine attaching fixed rate parameters to break commands may fix this issue.

[marrie]

When using this option in nvda,I too find the delay a bit long. I would like to be able to adjust the delay from 0 milliseconds to whatever would be an ultimate length in milliseconds is needed. If this could be implemented I would stop usign the enhanced phonetic add on out at this point in time in a heartbeat. thanks.