[Rwp] Plug-in hot spots

[Chris Belle]

Haven't used that tool yet, the one I used the most is autohotkey.
That
  a great tool,
but having tight integration with the screen-reader like hsc has it's 
definite advantages.
But these third party tools have the advantage of working even with no 
screen-reader in place.
Snowman's hotspot clicker tool is the most sophisticated,
and versatile tool to date, but it's a jaws only solution.
Kontakt does crazy stuff like leave windows open when you open other stuff,
and it covers up what you want, so you have to check for things to be 
right when you load libraries,
I know NVDA can do this sort of thing,
technically, but it has to be invented.
My vote would be to build a tool which isn't specifically tied to Osara, 
but can be used in any NVDA thing,
then other apps can built on it not just reaper.
Building on the concept of golden cursor but make it be able to tell 
child windows, and search for text, and color and do all that stuff 
eventually.
A lot of work I know,
but this would eventually make NVDA the equivalent of
jaws and window-eyes such,
for this sort of screen-scraping.
I suspect with NVDA's
abilities now, some things could probably be done with it that the big 
guys can't do,
once we catch up on the basic stuf.
of just differentiating windows and such.


On 3/9/2016 2:15 AM, Gavin Grundlingh wrote:
> Hi,
>
> I created hot spots for Kontakt 5 in AutoIt, using a similar method 
> for calculating coordinates to what Jamie used in the NVDA add-on for 
> Sonar. So far, at least, it appears to work under very different 
> screen resolution / DPI settings on different versions of Windows 
> running on different machines. I calculated the coordinates according 
> to the actual plug-in window, so the spots work for bridged and 
> non-bridged modes, too. My next test will be to see if different hosts 
> freak out when using the spots, or if they'll just be nice and work.
>
> Of course, I realise Kontakt is way, way more complex than Dimension 
> Pro or Sfz, but I thought I'd mension my spot creation for it here to 
> outline my methods.
>
> Regards,
>
> Gavin
>
>
> On 2016-03-09 06:49, James Teh wrote:
>> Hi plug-in hot spot creators (HSC, AutoHotkey, whatever),
>>
>> As I've watched discussion about creation of hot spots for plug-ins 
>> and associated problems, I've been starting to wonder about why they 
>> aren't done in a way which makes them more reliable across different 
>> configurations. I don't have much experience in this area, so there 
>> may well be a good reason and I'm just not seeing it. So, I'd 
>> appreciate some thoughts on the below.
>>
>> In the following discussion, let's assume we're dealing with simple 
>> hot spots; i.e. spots which don't change such as the program browser 
>> button in Dimension Pro, the load button in SFZ, etc. I realise there 
>> are many cases where this isn't the case, but that's beyond the scope 
>> of what I'm getting at here.
>>
>> As I understand it, there are two main problems that cause basic hot 
>> spots to be unreliable:
>>
>> 1. Different screen resolutions/DPI settings. If hot spots are 
>> created for one screen configuration, they sometimes don't work on 
>> other configurations.
>> I notice that even though some hot spots use relative coordinates, 
>> they're still absolute as far as the window is concerned. That is, 
>> they don't account for the window being a different size, only the 
>> window being in a different starting position. So, why not use width 
>> and height fractions? So, if the coordinate is half way across the 
>> width of the window, you would store 0.5 instead of an absolute value 
>> like 200. This way, if the window shrinks to half size, you can still 
>> calculate the correct coordinates. In practice, some windows probably 
>> don't resize everything in direct proportion, but I would have 
>> thought this would be more rare than not.
>>
>> 2. Different applications. Hot spots created for Sonar don't work in 
>> REAPER and vice versa. Even in REAPER, hot spots created for bridged 
>> don't work in non-bridged.
>> From what I've seen, even hot spots that are relative are calculated 
>> relative to the top level window. The problem is that the top level 
>> window is part of the host (e.g. REAPER), not the plug-in. That means 
>> it's going to be different for every host. So, why not calculate the 
>> coordinates relative to the window for the plug-in itself? The 
>> plug-in should render exactly the same way no matter where it's 
>> hosted. Therefore, if coordinates are all relative to the plug-in 
>> window, they will work the same regardless of the host used.
>>
>> On a related note, I'd be interested to know whether it'd be worth 
>> implementing some kind of basic hot spot support into OSARA. The 
>> question is what kind of complexity is needed for the majority of 
>> plug-ins. I know HSC has support for searching for colours, etc., but 
>> I never quite grasped how this was applied in practice.
>>
>> I'd appreciate any thoughts.
>>
>> Jamie
>>
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp
>