Is it possible to create a toggle to silence the title of Reaper's main window? about osara HOT 12 CLOSED

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?

from osara.

from osara.

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

from osara.

@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...?

from osara.

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.

from osara.

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.

from osara.

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.

from osara.

@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.

from osara.

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.

from osara.

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.

from osara.

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.

from osara.

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

from osara.