osara
osara copied to clipboard
jcsteh
loss of focus of osara and inability to work in track display.
Hi James, it often happens to me that when I am in reaper and focusing on a different application or on the desktop, or when closing NVDA and opening jaws or vice versa, when I return to reaper "TCP", I dare not announce the tracks anymore by scrolling with the arrows. To fix it I have to download jaws or NVDA, possibly not being focused on reaper and then everything goes back to working as before. Sometimes I am forced to download and completely close reaper before restarting NVDA or jaws for the situation to return to normal. Has anyone ever reported this problem? Maybe it's my fault or my system, but I've heard that others here in Italy have warned it. Thank you very much for your patience.
I've seen that being complained about a few times @ranetto, but as yet, I've not seen reproduction steps. That's what we'll need to have any chance of fixing it. If it happens often, then reproducing the problem should be possible.
Thanks Scott, now I will try to find a correct sequence in which it always happens and will post it as soon as I can. However I can say that it has only been happening for a few months with the new Osara, it had never happened to me before.
Hi Scott, I did a test two or three times that always gives me the same result: when you have a finished song, put for example two versions in the render queue with two formats, "wave" in the first tab and "MP3" in the second tab. Then put in the queue also the single base of the song always with the two formats as above. With "CTRL ALT Q" go to the queue and ask to redirect everything. You can now go to the desktop or wherever you want. At the end of the "rendering", go back to reaper and osara will be stopped on "TCP" but will not be able to select and above all to let you listen to the tracks on which you scroll with the arrows. In reality, clearly the queue is still open and emptied of the files to be played. If you can with jaws, "insert f10", or NVDA to focus the queue window with the "listview" and the rest and close it, everything will return to normal, otherwise you will not be able to focus on the tracks. Since this has never happened, I don't know if this is reaper or osara 6.15 behavior. What do you think about it? What will James think?
Followed those steps and couldn't reproduce with NVDA here. The empty render queue dialog gains focus as expected when I switch back to Reaper. Does this happen for you with both JAWS and NVDA?
So @ScottChesworth and @ranetto seem to be seeing slightly different focus results here, even before we get to discussing OSARA messages. @ScottChesworth gets focus in the empty render queue dialog, which is what I'd expect. But @ranetto apparently gets focus on the TCP. That difference is in itself strange. I wonder if we're missing a step here. Certainly, if the empty render queue is indeed focused, I wouldn't expect TCP commands to work.
If you close NVDA and open JAWS, it's true that you won't get speech. The reason is that OSARA now uses UIA notification events for NVDA because it allows OSARA to interrupt speech, provide feedback in places it couldn't before (e.g. the MIDI events list), etc. However, we can't use UIA notification events for JAWS because JAWS ignores them, so if OSARA detects JAWS at startup, it disables the new mechanism. Since JAWS wasn't running at startup, OSARA would have chosen the new UIA code, which of course won't work with JAWS.
hi James, I actually find that if I take off the queue list during its execution, I focus on the desktop, when I return to reaper, a strange situation occurs where the foreground window is really reaper and I can activate its menus, but the focus has been lost and reaper is not able to take it, in fact probably the keys do not really work on reaper, because the keyboard seems and is actually working on the queue list which after its execution is empty. If I focus it with jaws or NVDA, then I have keyboard control over the queue list and closing it returns everything to normal. Maybe it's a problem of the last reaper? I found a strange focus compromise in reaper 6.15 also on the bay window, which cannot be detected nor focused by jaws and NVDA if one of its objects is not activated with a mouse click. Clearly when this window is unfocused it doesn't even expose its "handle". Can it help?
I wonder if we're missing a step here.
Ditto. Hey @ranetto , can you make an audio recording of the steps you're taking there? Doesn't have to be high quality, just a voice note on your phone or whatever will do. I wanna check I'm following exactly the same process.
Hi Scott, hi James, I made and recorded here the proof that I can always reproduce: sorry for my lousy english I hope you will be able to understand me, I am attaching here the zipped file and recorded with the voice memo of iphone: thank you for understanding I hope it can be useful and help us understand the problem: I use windows 7, I do not know if there is a management of this type of processes other than windows 10, but if you think this is the case I can try to reproduce it on windows 10 too. demo reaper Q.zip
Got it, thanks dude. I think there were a couple of differences between our tests, so just to clarify:
- Are you hitting Control+Alt+Q from within the Render dialog, or are you closing the Render dialog first and hitting Control+Alt+Q from the TCP.
- Do you have the check box that automatically closes the window when a render completes checked?
Hi Scott: then from the TCP, I open the render window with ctrl alt Q, then while redirecting I leave it open I go to the desktop: I don't close the queue window, and when I can refocus it I close it with the button to close it and not with the shortcut. I haven't checked the box to automatically close the render window at the end of the render but I'm going to personally check if the list is empty. By doing this, if I decide to redirect only one element of the list, I could see those not yet redirected at the end of the procedure.
Gotcha. I need to re-test then and follow your steps more closely. Will do that later and report back asap.
Hi Scott, how did your tests on this problem go? Did they confirm or deny those made by me? Thanks Scott
I've re-tested this a bunch of times and tried the following variables:
- Automatically close check box when render is in process checked and un-checked.
- Queued render focused and un-focused when I click Render All button.
- Reaper 6.15, 6.14 and the current +dev build of 6.16 at time of writing. can't get it to happen here at all so far. Back to you @jcsteh. My cup of ideas hath run dry.
But no Scott, don't worry, then you want either that it is my windows 7 that works badly, or it is generally windows 7 that has this problem and you don't use it anymore. However, if no one complains, we try again to ask and otherwise we close it. How about Scott and James?
Can you try reproducing it on your Win10 machine as mentioned earlier in the thread and report back, @ranetto? Do we have any other Win7 users on here who can test the reproduction steps in this audio file? https://github.com/jcsteh/osara/files/5566690/demo.reaper.Q.zip
Sure Scott, I'll try it between today and tomorrow and I'll let you know everything! Thanks
Hi Scott, I have carried out the agreed tests, on windows 10 and here in my workstation the same fact occurs, after the "rendering" I am in the condition that I have shown you. To be fair I must tell you that I have performed the tests on my windows 10 "Microsoft Windows Version 1709 (build SO 16299.904) "and therefore may not have feedback on the latest version of windows 10.
Hmmm, so it's not the OS and it's not the screen reader. I've no idea what the variable is here. Any thoughts on other stuff to try, @jcsteh?
Hi Scott, I add that clearly in order to have time to rehearse I redirected a song that would take some time, at least to be able to try: probably not a problem of osara but perhaps of reaper: maybe there is some reaper setting that could affect? Anything about visualization? I have enabled only the master in visualization, I am not full screen, and I have enabled the "Always on top", however we have not had any other feedback from other people and so if no one tries it maybe it will have to be closed. What do you think?
Hi,
I wanted to point out that the malfunction reported by Ranetto also happens to me, both with Jaws and with NVDA. Windows 10 PRO x64 IT, V2002 (build SO 19042.630) Reaper x64 v6.15 Osara 2020.1pre-333,29a87ac2
Thank you.
Rispondi direttamente a questa email, visualizzala su GitHub o annulla l'iscrizione.
Il 23/11/2020 16:01, ScottChesworth ha scritto:
Ooh, that could be it! Disable always on top and re-test.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/382#issuecomment-732216094, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARIP4YKXAWKFS5RE5QY65T3SRJ2LNANCNFSM4T2ETL2Q.
Hi Scott and James, I tried removing the tick for the foreground but nothing changes: what happens here with both NVDA and jaws is as if in reaper 6.15 this window was interpreted by reaper as a sort of modal or dialogue, in which if you don't do something with the close, the keyboard stays there because it waits for you respond to the dialogue and then even if reaper is actually in focus and can expose its menu bar it cannot be commanded until you focus again on the render queue window where the keyboard can act and close it with the button. I don't know what to say Scott! Let's see if anyone tells us anything about their experience.
I'd be interested to know if this problem has gone away with the latest snapshot due to the workaround for #801.
I haven’t observed this problem in some time using JAWS (although it had only happened infrequently before). Is it possible that something changed in Reaper 7? In any case, I never found a way of reproducing the issue.
--Pete
From: James Teh @.> Sent: Saturday, December 9, 2023 9:18 PM To: jcsteh/osara @.> Cc: Subscribed @.***> Subject: Re: [jcsteh/osara] loss of focus of osara and inability to work in track display. (#382)
Can anyone still reproduce this?
— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/382#issuecomment-1848853280 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJLWAOGJZOWEASMN2WTYIUZV5AVCNFSM4T2ETL22U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBUHA4DKMZSHAYA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
It's more likely that the hacks i landed to fix #801 dealt with this as well.
@ranetto and @TrapYanto, can you grab the most recent OSARA snapshot and latest REAPER, retest the steps earlier in the thread and let us know whether this is resolved now?