jcsteh
When the Parameter combo box in the Parameters dialog gets focus, rebuild the parameter list.
This deals with cases where changing a parameter value also changes parameter names; e.g. changing the bad type in ReaEq. Fixes #706.
This is a fairly naive solution in that it doesn't bother to keep track of whether a parameter value has actually changed. Thus, it rebuilds the parameter list more often than it strictly needs to. That said, unless this actually causes performance problems for plugins with large numbers of parameters, I'd prefer not to complicate the code here. It should be possible if this does cause problems, though.
Either way, this needs testing on plugins with large numbers of parameters.
Build failed! Build osara pr707-875,3738ff48 failed (commit https://github.com/jcsteh/osara/commit/3738ff482f by @jcsteh)
Oh look. It failed on Mac. What a Zarqing surprise. No idea what to do about that. SWELL doesn't support WM_SETFOCUS either, so I can't use that either.
... SWELL doesn't support WM_SETFOCUS either
Looks like that assumption is no longer correct. See https://github.com/justinfrankel/wdl/commit/20057d485a4ee345fb8db6c846f124672b300f7c It will of course require a bump of swell/wdl.
Build failed! Build osara pr707-962,e27b97f7 failed (commit https://github.com/jcsteh/osara/commit/e27b97f703 by @jcsteh)
Oh. I forgot I need to change this to use WM_SETFOCUS instead of CBN_SETFOCUS. That's going to require implementing a WindowProc for the combo box, which is annoying, but should be possible.
Build succeeded! Build osara pr707-997,24359a4e completed (commit https://github.com/jcsteh/osara/commit/24359a4e42 by @jcsteh) Downloads:
Would someone be able to test this on Mac? See https://github.com/jcsteh/osara/issues/706#issue-1160737802 for testing instructions.
Oh, and it still needs testing with plugins with a large number of parameters, either on Windows or Mac.
Just did some testing on both Windows and Mac with SurgeXT. It's both a plugin that has a lot of parameters (about 2800 for the VST3) and dynamically changes their names. FOr the test I located the FX A1 FX type parameter and changed it from off to one of the effects, which causes the next parameters to change based on the selected effect.
- On Windows, the names change correctly but there's now some lag when the combo box gets focused. With NVDA and ZDSR it's about a second, with Narrator it's a bit less but still noticeable.
- On Mac, there is no lag when you tab into the popup, but the names in the list don't update. You do hear the new names if you use the CTRL+Tab shortcut however.
Would this be any easier to do if #534 were implemented? I suspect it might introduce even more headaches but I figured I'd throw it out there ☺️
On 24 Aug 2022, at 13:59, James Teh @.***> wrote:
Oh, and it still needs testing with plugins with a large number of parameters, either on Windows or Mac.
— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/pull/707#issuecomment-1225622850, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABAABTPAF4LXJLDF23HJLILV2YFBHANCNFSM5QB2VY3Q. You are receiving this because you are subscribed to this thread.
On Windows, the names change correctly but there's now some lag when the combo box gets focused. With NVDA and ZDSR it's about a second, with Narrator it's a bit less but still noticeable.
Yeah, that's what I was afraid of. That's OSARA trying to fetch all the parameter names again.
On Mac, there is no lag when you tab into the popup, but the names in the list don't update.
Ug. Terrific. That means the code isn't actually working at all, probably because the focus notification doesn't work properly on Mac even though it now should.
Would this be any easier to do if #534 were implemented?
No; I suspect the lag and focus failure is not related to the type of control.
Actually, I guess it's possible the lag is accessibility events being fired. Hmm.
Sorry if this is a duplicate post, but I don’t think my last message got to the list. Here it is again:
I don’t know if this is an Osara issue or related to how the JAWS scripts are handling this, but from the sound of this issue, I thought this fix would have addressed the curious behavior I am seeing.
I was using the TriLeveler plug-in and noticed that, as I changed parameter values in Osara’s parameter list, I was getting non-real world values. When focus was first on the value of a parameter, however, the values were real world.
Specifically, here is what happens:
- Hit “p” to get into the Osara parameters list for the TriLeveler plug-in on the track.
- Tab to the first value, trim, in the list and see that it says something like 2.5 db.
-
- Hit PageDown and the value changes to something like 0.57%.
- Shift+tab back to the list of parameters, arrow to another parameter, and then arrow back to the trim parameter.
- Tab to the v value and now I hear the real world value of 2.1 db instead of something like 0.57%.
Thus, as I change parameter values, they are changing but are not being reported correctly.
If you think it is a JAWS scripts issue I can pass it along to Jim to see what he can do.
Thanks.
--Pete
I don’t know if this is Osara issue or related to how the JAWS scripts are handling this, but from the sound of this issue, I thought this fix would have addressed the curious behavior I am seeing.
I was using the TriLeveler plug-in and noticed that, as I changed parameter values in Osara’s parameter list, I was getting non-real world values. When focus was first on the value of a parameter, however, the values were real world.
Specifically, here is what happens:
- Hit “p” to get into the Osara parameters list for the TriLeveler plug-in on the track.
- Tab to the first value, trim, in the list and see that it says something like 2.5 db.
-
- Hit PageDown and the value changes to something like 0.57%.
- Shift+tab back to the list of parameters, arrow to another parameter, and then arrow back to the trim parameter.
- Tab to the v value and now I hear the real world value of 2.1 db instead of something like 0.57%.
Thus, as I change parameter values, they are changing but are not being reported correctly.
If you think it is a JAWS scripts issue I can pass it along to Jim to see what he can do.
Thanks.
--Pete
@ptorpey, that wouldn't be addressed by this fix, even assuming it worked satisfactorily. That is due to the plugin not supporting reporting of friendly values for any value other than the current one, so OSARA can't get the friendly value until after the value has been changed in the plugin. That also prevents OSARA from snapping to the next discrete value if the parameter is not entirely continuous.