search

jcsteh / osara

OSARA: Open Source Accessibility for the REAPER Application
GNU General Public License v2.0
127 stars 46 forks source link

The problem that osara will read aloud 0.0 when switching between Automation mode again #802

Open c469591 opened 1 year ago

c469591 commented 1 year ago

Hi friends. When I press ctrl+f12 and check this option Report changes made via control surfaces Once I switch to Automation mode, it keeps reading 0.0 aloud. Whether I press shift+l to switch modes in the options, or press ctrl+shift+\ The same thing happens when I switch to Automation mode. The content that is supposed to be read aloud will be interrupted and become read aloud 0.0. Can this problem be fixed? Thank you!

ScottChesworth commented 1 year ago

Short-term workaround, you should still get spoken feedback when controlling automation via the described keystrokes. So far as I can tell from the OP, having Surface Feedback enabled isn't necessary.

ScottChesworth commented 1 year ago

This is however a thing that's plaguing the folks doing good work with the new CSI accessibility, so I've assigned high priority. I don't think CSI itself is a contributing factor because extraneous feedback occurs without CSI in the equation.

jcsteh commented 1 year ago

I understand the issue with shift+l. What's the other command that causes problems? How does this cause problems for CSI?

jcsteh commented 1 year ago

Once I switch to Automation mode, it keeps reading 0.0 aloud.

When you say "keeps reading", do you mean it gets read repeatedly forever or just once?

ScottChesworth commented 1 year ago

How does this cause problems for CSI?

It's not exclusive to CSI, but a productivity killer around surface usage/feedback across the board. Pasting the most recent report from RWP for ya. I was intending to bring this over to GitHub later today, just haven't had a chance to check open issues.

Quoting Paul Warner: Using NVDA with Windows 11, I am also using an X-Touch Universal control surface. The problem is that very often, but not always, NVDA speaks the track volume of a track which has had volume automation applied to it previously. So, arrowing down the tracks in the TCP, I'm hearing '-13dB Atmosphere' instead of the name of the currently selected track. I also get this when arrowing down the list of effects in a track's FX window.

I was advised to turn off the reporting of control surface changes in Osara preferences whenever this happens. But I am now heavily using my X-Touch control surface and I do need to hear the feedback when I make changes using that. In addition to the random speaking of the automated track's level, there is no spoken feedback from the X-Touch, even when Osara is set to report control surface changes. I tried muting the track whose automated volume was being spoken but that didn't work. What did work was bypassing the volume envelope for the automated track. This then caused NVDA to keep repeating the automated volume level of the other track I had automated. Once its volume envelope had been bypassed, I was able to use the X-Touch normally with proper feedback.

This is a serious bug in Osara which is preventing proper use of reaper as well as my X-Touch. When I raised this issue the first time, I don't think it was realised that simply turning off the reporting of control surface changes could not be a viable solution. For those of us using surfaces, we need to have that feedback sometimes and this functionality is being killed by this bug. Can it please be investigated?

jcsteh commented 1 year ago

The problem here is that REAPER is somewhat over-chatty in its firing of surface notifications, which is not unreasonable given that it's designed for surfaces which display things and not surfaces which talk. It tells surfaces about the volume of a track even if it hasn't changed sometimes. OSARA already caches a bunch of stuff - mute, solo, arm - in an effort to try to avoid extraneous reporting, but at some point, adding more stuff to that cache is going to become infeasible. If we end up having to cache everything that can possibly be automated, that's going to become unwieldy very fast. Is it only volume levels that get announced or other parameters as well?

Paul's complaint in the past was that OSARA reports values as the automation changes them; e.g. during playback or navigation. I really don't see how we can fix that. A surface moves motorised faders in response to automation, so REAPER tells surfaces about automation to enable that. OSARA can't know whether it's being told about a change made by the user on the surface or a change being played back via automation. I think this could only be fixed by some different API in REAPER, but I don't know what that would look like. Maybe some API on IReaperControlSurface to specify that this surface doesn't want to be told about automation notifications, only changes made via other surfaces?

ScottChesworth commented 1 year ago

Maybe some API on IReaperControlSurface to specify that this surface doesn't want to be told about automation notifications, only changes made via other surfaces?

I can start a thread with Justin about that. Couple of questions:

  1. Do you want to be CC'd in?
  2. Would we want a front-end preference to control which API gets used? If so, do we need Cockos to provide that, or would it be a new entry in OSARA Config?
jcsteh commented 1 year ago
  1. Do you want to be CC'd in?

Yes.

  1. Would we want a front-end preference to control which API gets used? If so, do we need Cockos to provide that, or would it be a new entry in OSARA Config?

Any configuration here would be done by OSARA. I envisage that OSARA would explicitly choose to enable this new thing if appropriate.

Perhaps the only reason we'd care about automation notifications is to support movement of the slider as the value changes in the Parameters dialog. But now we have conflicting requirements. What if someone wants to use a surface but also wants to see parameter sliders moving?

The ideal API would tell us (for each notification) whether it was generated by the user or by automation. However, I can't think of a way to do that which wouldn't require an entirely new surface API, since you can't add parameters to existing functions. I guess OSARA could create two surface instances, one for all notifications and one on which it just asks for user generated notifications, but that's pretty horrible.

jcsteh commented 1 year ago

Can you think of any other reasons we'd care about surface notifications generated by automation?

c469591 commented 1 year ago

Hi, sorry, my translation did not express my meaning correctly. When I press ctrl+shift+\, I can also switch to Automation mode, there is also the problem of reading aloud 0.0. Also, it will only read aloud once, every time I press it. About why I have to turn on ctrl+f12 for this problem. Because I have a friend who wrote a software that allows me to control the reaper by pressing quick keys in other places. And this software is by simulating control surfaces to achieve this purpose. In addition, those who use control surfaces, sometimes if you want to switch between Automation mode, there will also be this problem that I mentioned. So, I think we should still need to solve this problem. I do not understand the development of the software, so I'm counting on you all. Thank you all!

Translated with www.DeepL.com/Translator (free version)

jcsteh commented 1 year ago

This one's complicated/blurry enough that I don't have super clear thoughts yet, so I started a thread with Justin myself and CCed @ScottChesworth .

jcsteh commented 1 year ago

I worked with Cockos to get some API changes implemented and tried to fix this in #804, but ran into an impasse with @leejul with regard to the user experience for surface feedback. It seems there are significant differences in opinion among key people with regard to how surface feedback should work.

As far as I'm concerned, I'm not willing to work on this any more until there is a clear, thorough plan which covers the various scenarios involved with surface control and what should be reported in those scenarios. This would need to be done in consultation with all the key people using surface feedback who have strong opinions here and there would need to be agreement among them. Input from one key person is not sufficient, since the opinions are just too varied here. I am not willing to be the person who coordinates this, but if someone else is up for it and they can put forward a plan with solid consensus, I'll consider looking into it, which will probably involve working with Cockos for more API changes.

reaperaccessible commented 1 year ago

Hi James, Here is the email I sent to the CSI list and at the bottom of that message you have the responses from the users. So far, 3 users have responded.

Subject: Survey of control surface users

Hi guys, I proposed a solution to James which seems to me to be the best but I would like to have your opinion. I believe that the best thing about a situation such as this is to give the freedom to choose the verbosity according to the user's preferences. I suggested that he create a toggle action to enable or disable control surface feedback for each automation mode. So the actions could be the following: OSARA: Toggle Report changes made via control surfaces in Write Mode automation OSARA: Toggle Report changes made via control surfaces in Read Mode automation OSARA: Toggle Report changes made via control surfaces in Touch Mode automation OSARA: Toggle Report changes made via control surfaces in Latch Mode automation OSARA: Toggle Report changes made via control surfaces in Trim/Read Mode automation OSARA: Toggle Report changes made via control surfaces in Latch/Preview Mode automation OSARA: Toggle Report changes made via control surfaces in Trim Mode automation I could assign these toggle actions to dedicated automation mode buttons but with Shift. Example: Write, Shift+Write button enables or disables the return of control surfaces in Write mode. Touch, Shift+Touch button enables or disables the return of control surfaces in Touch mode. So if I press Shift+Write to disable feedback from control surfaces in Write mode, NVDA will no longer speak in Write mode. Even if I change mode and I go back to Write mode, NVDA won't speak anymore. If I want to re-enable feedback, I have to press Shift+Write again. This way, all users can configure the verbosity of the automation modes according to their preferences. What do you think about this solution?

Reply from Steve Matzura Simply stated, you've covered everything. Who could ask for anything more?

Reply from Ludovic Sansone Excellent solution. In this way each user has the choice to configure the verbosity as he wishes, for each mode of automation.

Reply from Jim Nosewortey Hello: I totally agree with the path that you propose. Great work: Thanks all over the place.

jcsteh commented 1 year ago

Thanks for your thoughts and for taking the time to survey users. I don't think you've fully represented the entire problem, though. You've provided a solution, but without giving users the full context of the problems that we're dealing with.

There are two main issues with the solution you've presented:

  1. This would create a lot of additional settings in the OSARA config dialog. OSARA toggle actions map to settings and these create a lot of clutter in that dialog. I guess I could try to find a way to de-couple these.
  2. This doesn't deal with the issue discussed in this report; i.e. that certain REAPER actions (e.g. switching between automation modes) causes spurious surface feedback to be reported. That requires that we ignore certain surface feedback. Will users really be happy with turning off surface feedback and turning it back on every time they want to perform one of these actions?
reaperaccessible commented 1 year ago

Hi James,

  1. This would create a lot of additional settings in the OSARA config dialog. OSARA toggle actions map to settings and these create a lot of clutter in that dialog. I guess I could try to find a way to de-couple these.

You could make a dedicated menu, indeed. But these actions will be dedicated to control surface users. So why add these actions in the OSARA settings menu? Why would a user want to use these actions if they don't have a control surface?

  1. This doesn't deal with the issue discussed in this report; i.e. that certain REAPER actions (e.g. switching between automation modes) causes spurious surface feedback to be reported. That requires that we ignore certain surface feedback. Will users really be happy with turning off surface feedback and turning it back on every time they want to perform one of these actions?

I fixed a problem with duplicate verbosity when pressing a fader. The normal behavior is as follows: Pressing and leaving your finger on the NVDA fader speaks the value. You lift your finger from the fader, NVDA announces the value again. I modified CSI so that NVDA speaks the value only when you lift your finger. Otherwise, NVDA talks too much. I don't know if Cockos or you can solve this problem. But if not, I don't understand problem with the change of automation mode. Do you have an example so that I can understand. If I understand correctly, you are talking about the action OSARA: Cycle automation mode of selected tracks. If so, there is no problem with this action and NVDA's return. I am on the CSI user list and no one has reported this problem to me. I confirm that no one has reported to me the problem that David mentions in issue 804. I don't have this problem, either with CSI or in mackie Control mode. It takes me an example that I can reproduce here.

Thanks my friend.

jcsteh commented 1 year ago

But these actions will be dedicated to control surface users. So why add these actions in the OSARA settings menu? Why would a user want to use these actions if they don't have a control surface?

Currently, OSARA settings are defined in a single place. That puts them in the OSARA config dialog and also gives them a toggle action. It's not currently possible to define them separately so that they have a toggle action without showing them in the dialog. Fixing that would require some refactoring, which is possible but requires some work.

I don't understand problem with the change of automation mode. Do you have an example so that I can understand. If

See https://github.com/jcsteh/osara/issues/802#issue-1412529602 or your own issue #813. That is caused by surface feedback reporting parameter changes, since REAPER notifies surfaces of many parameters whenever you change certain settings, especially automation modes.

reaperaccessible commented 1 year ago

Issue 802 and 813 is exactly the same problem. This issue has been resolved with this version of OSARA, osara_2022.1pre-1035,6a7d1f84. This is the first test I did after installing OSARA. Now when switching between automation modes with Report changes made via control surfaces is enable, NVDA speaks the modes correctly and this issue is fixed. I found it weird that you didn't close this issue. So, if I understand correctly, you didn't change anything in OSARA's code and this problem is gone? It may be the latest version of Reaper then. In any case, everything is ok, tested on 3 machines. In my opinion, it is useless to add these action toggles in the OSARA settings menu. We only need actions that I can add in CSI.

jcsteh commented 1 year ago

Intriguing. I didn't change anything in OSARA that would have prevented those messages from being spoken when changing automation modes, so yeah, I wonder whether something got fixed in REAPER. @c469591, can you please test this with latest REAPER to verify this?

reaperaccessible commented 1 year ago

!Hi James, You can test this on your machine; When Report changes made via control surfaces is checked, use the OSARA action: Cycle automation mode of selected tracks to cycle between modes; Before, NVDA spoke either track name, project name or track volume value on 2 automation modes. automation mode trim/read for selected tracks and automation mode touch for selected tracks Now everything is spelled out perfectly.

jcsteh commented 6 months ago

Maybe we can take the auto mode changed stuff from #804 and split the auto playing changes out for now. Let's give it a shot and see whether it works.