While I like the change that this becomes configurable, I'm not sure about changing the length. Note that indentation beeps is especially helpful to people with perfect pitch, as they can hear the exact indentation level based on the note of the beep. Distinguishing differences becomes harder when shortening the beep. I myself can distinguish them just fine, but it definitely needs more attention.
Would you be open to a lenght of 60ms?

Note that indentation beeps is especially helpful to people with perfect pitch, as they can hear the exact indentation level based on the note of the beep. Distinguishing differences becomes harder when shortening the beep. I myself can distinguish them just fine, but it definitely needs more attention.

I personally don't agree, if the beeps are long enough for progress bar beeps, something I assume perfect pitch could also be used for to tell what percent you're at, it should be good enough for coding.

@trypsynth seems like a matter of personal preference. As said, I can personally deal with it just fine, but I'm not sure about others.
Is the idea of shortening the beeps based on a user suggestion or real problem we want to solve, i.e. are they perceived as too long? If not, I think I'd prefer leaving the length as is.

@LeonarddeR I currently don't use indentation beeps because I find them disruptively long. In conversation, @trypsynth also mentioned that they find them too long. I fail to understand how 40ms can be long enough for progress bar tones but not for indentation tones.

I fail to understand how 40ms can be long enough for progress bar tones but not for indentation tones.

Because recognizing an exact pitch value, absolutely or relatively, is much more useful for indent size than for progress bar:

• I need to precisely know how many tabs my code is indented
  absolute indent size
• on the opposite for a progress bar, I just to know that it is going forward and to have an idea of the speed it increases. But I do not know, when a beep occurs, if I am at 40% or 70%. I just have a vague idea if the pitch is low or high.

In any case, I have not yet any opinion on the duration. Making this configurable will allow to test it.

@CyrilleB79 explained this much better than I ever could. Thanks!
Note that @derekriemer is the original author of the feature. May be he chose the current length for a particular reason?

@LeonarddeR, @CyrilleB79 would you be more comfortable if we retained a tone duration of 80ms for the moment and added a means of adjusting the length in NVDA's settings? That would solve mine and @trypsynth's problem, while not changing things for folks who prefer the current duration.

@SaschaCowley I wouldn't necessarily want to go that far. I just wanted to share a concern that might be a show stopper for others. Happy if the default becomes 40ms. We can always make it configurable when people start complaining afterwards.

can this get a changelog entry under changes?

@seanbudd done

I don't either have an opinion with the current duration of this beep, neither have heard any concern from someone else about it.

Making it configurable, at least in config spec, will help to experiment.

I'd say that you may shorten it during alpha stage to test. Unless there is a real demand, I'd not make it configurable in the GUI to avoid cluttering the GUI with any single little parameter. Let's try to choose a value that suits everyone if possible.
Also, if the value does not meet the need of everyone and every use case, having the value configurable in the config spec allos to easily code an add-on for more specific needs.

When I designed this feature, I picked a length that sounded good to me at the time. There was no rhyme or reason to it. How hard would it be to scale the length down with the speed of speech somehow, on a per synth method, or expose something under advanced settings? I like it the way it is, but could probably get used to shorter beeps. Keep in mind that people who don't have perfect pitch may want a longer beep to get a good feel on the current pitch relative to the other pitch.

This is a bit awkward to me when using VS Code in diff view, since VS Code also emits tones to indicate changes, and since the duration of NVDA's indentation tone is now shorter, I have to concentrate much harder to make sure I didn't mishear the indentation. I have gotten confused in some cases when the indentation is almost the first level or 0 for that reason.

I started to use 2026.1, and finding this beep a bit too short to me. I think it's because it completely overlaps with beginning of speech. I'm currently dealing with this by turning down the speech a bit. Not demanding changes or the configurable option immediately, but just sharing my first thought.

Hi @yncat, thanks for the feedback. Would you mind adding your comment to #19353 as well, as that is the issue that tracks making this customizable from NVDA's settings dialog?

In the meantime, if you wish to get back the old indentation tone duration, open NVDA's python console (NVDA+control+z), enter the following line exactly, and press enter:

config.conf["documentFormatting"]["indentToneDuration"] = 80

You can then close the Python console with escape. As long as you save your NVDA configuration (by default this happens automatically when you exit NVDA, but you can also press NVDA+control+c to do it manually), this change will persist across NVDA restarts.

@SaschaCowley I've commented to the linked issue. Thank you for providing instructions of adjusting the duration persistently!