Is it possible to create a toggle to silence the title of Reaper's main window?

[Lo-lo78]

Hi, unfortunately I'm noticing that the title of the main Reaper window continues to cause problems and interferes with the workflow. I'll give two examples:

1. the most serious. §When I do the action: "View: Jump (go) to time window" when I am in play the main window of Reaper is always read by the NVDA screen reader on Windows. I don't know about other cases.
2. When running scripts, messages often conflict and overlap. Is it possible to find a way to silence the title of the main window with a toggle? Other problems of various kinds could arise in the future. You can do something with the NVDA dictionary but it's out of my reach. I don't know how to use regexes in an advanced way. Thank you!

[ptorpey]

FYI, here is what JAWS reports when running that action:

Jump to time/marker/region: dialog Jump to: mm:ss.xxx jump to minutes:seconds.fraction mm.bb.xxx jump to measures.beats.fraction h:m:s:f jump to hours:minutes:seconds:frames preface with + or - for relative jump preface with i to jump to time in selected item preface with tXiY to jump to time in track X item Y mN or m’name jump to marker by number or name rN or r’name jump to region by number or name k’name jump to take marker by name Jump to: Edit 1.2.45 track list

Seems like JAWS is reading the entire dialog.

--Pete

From: Lo-lo78 @.> Sent: Thursday, March 28, 2024 12:21 AM To: jcsteh/osara @.> Cc: Subscribed @.***> Subject: [jcsteh/osara] Is it possible to create a toggle to silence the title of Reaper's main window? (Issue #1038)

Hi, unfortunately I'm noticing that the title of the main Reaper window continues to cause problems and interferes with the workflow. I'll give two examples:

1. the most serious. §When I do the action: "View: Jump (go) to time window" when I am in play the main window of Reaper is always read by the NVDA screen reader on Windows. I don't know about other cases.
2. When running scripts, messages often conflict and overlap. Is it possible to find a way to silence the title of the main window with a toggle? Other problems of various kinds could arise in the future. You can do something with the NVDA dictionary but it's out of my reach. I don't know how to use regexes in an advanced way. Thank you!

— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/1038 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJKSQOOOIV55B65MFITY2OSEBAVCNFSM6AAAAABFMGECVWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYTENBUGM3TGNA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ScottChesworth]

This is about what's reported when dialogs/menus etc are closed/destroyed, not what's reported when the dialog loads.

[Lo-lo78]

@ScottChesworth

This is about what's reported when dialogs/menus etc are closed/destroyed, not what's reported when the dialog loads.

Exactly! I don't know if OSARA can intervene and I don't know if it is better to solve the problem with the screen reader. With NVDA you can create an addon or use dictionaries in an advanced way. In this way with NVDA the problem would be solved well. I was wondering if OSARA could handle these types of situations. Maybe Cockos could create an action or put a feature in the preferences to fix the problem...?

[ScottChesworth]

Maybe Cockos could create an action or put a feature in the preferences to fix the problem...?

That won't happen, the window does need a title bar. IMO this is best handled per screen reader, but let's see if @jcsteh has any ideas.

[Lo-lo78]

In addition to the problem of the out of control title there is also a random message that often appears or is deleted by the screen reader, dirtying the messages. I am referring to the words: "trackview" These 2 words often pop up a bit at random.

[jcsteh]

It's not possible for OSARA to silence this. I also don't think it should. Reporting a change in focus is a fundamental screen reader feature. When you exit a dialog, the focus is changing. Reporting nothing would potentially be very confusing and might lead users to think that focus just got lost in limbo.

[Lo-lo78]

@jcsteh Precisely for this reason I was thinking of a toggle. In this way the user can decide when to deactivate the reading of the main Reaper window. If OSARA can't do it, that's another matter. If you have a toggle, saying that the user might get confused seems exaggerated to me. The reality is that an addon needs to be made for NVDA since OSARA can't do it. The focus changes but getting lost in limbo seems exaggerated to me. Why has NVDA 2024 introduced the functionality of having synthesis not only muted but also active on request? Evidently users are not afraid of falling into limbo. However, that's fine. If you are convinced that users are like this, that's fine. In English I would have said it better. Mine seems like a controversy. It's just an observation.

[jcsteh]

Why has NVDA 2024 introduced the functionality of having synthesis not only muted but also active on request?

That's different because the impact and use cases behind that setting are very clear. If it's enabled, the user only wants on-demand reporting. In this case, the intent is much less obvious and much more vague. You want to disable reporting of the main window title... but what about the title of other windows? Why is the main window so special? What about exiting from a dialog in the MIDI Editor? Do we also disable the title there? And what if we disable too many titles? What if some users want some titles and other users want others? Do we end up with 57 settings, one for each window title?

But anyway, this is all somewhat academic because OSARA can't do it.

[ScottChesworth]

From the front-end it might look like OSARA already does this in some situations. A recent example is when choosing to go to a track from the context menu of a send or receive in the track parameters dialog, where the dialog gets closed and OSARA seems to report the newly selected track name nicely without interference from REAPER's title bar. However, if you check speech history, you'll find that the title bar did get spoken, as did another notification that says "pane", so our reporting relies on speech interrupt to get the information that's useful to the front of the queue. @jcsteh, how is that being handled? Do you have the report of the selected track on a short delay or something? I'd like to understand whether the result you got can be replicated when scripts are using outputMessage to report, that's what @Lo-lo78 is chasing, I think.

[jcsteh]

There's no delay. I just close the window and call outputMessage. I was actually concerned the title bar might clobber the message in this case, but it doesn't. I don't know why it's different for scripts. As long as the script's outputMessage runs after the window closes (or potentially on a timer), that should be sufficient.

I'd point out that this is a very targeted case. The original request included things like omitting the main title when dismissing the jump dialog. That would mean you'd press enter and just hear nothing, which is not acceptable IMO. I'm not necessarily against adding some easier way to make sure that script output interrupts focus reporting, since the output presumably provides more specific context in that case. But I'm not willing to put time into figuring out any solution which silences foreground reporting of the main window across the board.

[ScottChesworth]

Sure, understood. Gonna experiment with outputMessage on a timer, see whether I can find an approach that works. @jennykbrennan, how does VoiceOver cope when you go to a track from the context menu I mentioned above?

[jennykbrennan]

It selects the track and reports its name, no delay, no other speech.