-
Notifications
You must be signed in to change notification settings - Fork 46
-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable or Disable Report changes made via control surfaces actions #1054
Comments
Does calling ID _OSARA_MUTENEXTMESSAGE first silence the report? |
Sometimes it gets the job done but sometimes CSI has to run multiple tasks consecutively and then NVDA speaks gibberish and nothing can stop it except Ctrl or the end of his message. For some reason, in certain circumstances OSARA: Mute next message from OSARA is not sufficient, I have to add the action 3 times in a row. It's really not easy because I have to try all the formulas in order to find the right one. Sometimes I have to trigger the action at the beginning of the code, sometimes in the middle or at the end, it's never the same twice. I really think that 2 actions that could completely mutate OSARA while the code is running would be perfect, but again I'm not sure, I have to test it. But at the moment I can't do the tests I would like because I have no way to completely disable OSARA while the code is running. |
The idea is that you should run OSARA: Mute next message before any action that might normally provide feedback. If you're running two actions that might provide feedback, you need OSARA: Mute next message before each one; i.e. Mute next message, action1, Mute next message, action2. If you're seeing cases where that doesn't work, please provide specific steps to reproduce and we can look into it. |
Here is a lua script that is problematic. -- OSARA: Disable Report changes made via control surfaces -- Function to open track folder if necessary
end -- Function to select the last track in the track folder relative to the currently selected track
end -- Execute the function -- OSARA: Re-enable next messages from OSARA |
Looking at this code, you're calling mute next message in one place only: before calling reaper.SetOnlyTrackSelected. But reaper.SetOnlyTrackSelected isn't going to report anything, so you don't want to call it there. I would be calling mute next message only before the other Main_OnCommandEx calls. |
So something like this:
|
Nice, indeed, it works. -- Function to open the FX window of a track -- Function to output message via OSARA -- Execute the SWS_SELCHILDREN action -- Get the selected track -- Check if a track is selected
else |
I don't really understand what this code is doing. But I think you're still missing a key point here, which is that you should only call mute next message before an action which causes OSARA to report something. In this code, you're calling it before outputMessage, which doesn't make sense. Note also that muting OSARA isn't going to silence other speech from your screen reader. For example, opening a dialog, closing a dialog or focusing a control all cause speech output, but that output does not come from OSARA and thus muting OSARA will not (and cannot) prevent it. |
During code execution, NVDA tries to say lots of things but all at the same time so it's gibberish. |
I think it'd be helpful if you could provide a speech history log of what's being said. Having mute and unmute commands is risky. Putting aside the simple possibility that someone just forgets to unmute, you could also fail to unmute if you returned early from a function or loop or similar. That screws the user pretty badly. |
But honestly, the rule is fairly straightforward. If you're going to call Main_OnCommand or friends and that action is one of the actions OSARA supports (per the readme), call mute next message first. The other thing to keep in mind is that a global mute command would also mute outputMessage, which is, as I understand it, not what you want. |
I just realised one thing I haven't accounted for here is surface feedback. In that case, mute next message (or even a mute all action) isn't going to help because the point at which surface messages are sent is somewhat unpredictable. So you probably want to disable surface feedback before tweaking any parameters in the API. |
Would it be possible not to have the names of the following 2 actions stated by OSARA when they are triggered:
OSARA: Disable Report changes made via control surfaces
OSARA: Enable Report changes made via control surfaces
These 2 actions must remain silent for it to be usable.
In some very complex script or in CSI, I need to mutate the next message from Osara and disable feedback from control surfaces.
Once the script work is complete, I re-enable everything before the script out.
The problem is that these 2 actions make NVDA speaking.
So, this is very complicated to manage.
But at the same time, I would find it a shame not to have feedback on these 2 actions in other circumstances.
Or, maybe create 2 other actions that would completely mutate OSARA and one that would activate it.
Thanks to consider this request.
The text was updated successfully, but these errors were encountered: