[Rwp] Plug-in hot spots

[Gavin Grundlingh]

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
>