[Rwp] Plug-in hot spots

Wed Mar 9 05:30:46 EST 2016

I think you're missing my point. The top level window is not the 
application window, but nor is it the plug-in window. The top level 
window is either the bridge container or the FX Chain dialog, but it is 
*not* the plug-in window. The plug-in window is beneath that and 
contains *only* the plug-in controls, nothing else. If you could truly 
defining hot spots for the plug-in window, they would work in Sonar, 
REAPER without bridging and REAPER with bridging.

Jamie

On 9/03/2016 8:14 PM, Chris Belle wrote:
> I meant the plug-in window.
> Not the application main window.
> Yes, we need to zero in on the closest container,
> for some reason I was thinking hot spot clicker called the top level 
> window the child window,
> but yeh, when I made my sfz ahk thing for reaper years ago I did it 
> for the
> window opening up in a separate window, and the sfz window title.
> Like it's supposed to be.
>
>
> On 3/9/2016 3:59 AM, James Teh wrote:
>> My point is that the top level window isn't good enough. That's why 
>> it breaks when you use a different host or change bridging modes. The 
>> plug-in itself has a window beneath the top level window and I'm 
>> arguing that coordinates should be based off that window, not the top 
>> level.
>>
>> As for fractions being difficult for humans, that's certainly true, 
>> but I'm imagining a tool would calculate this for you. This is done 
>> already to some extent with HSC.
>>
>> Sent from a mobile device
>>
>>> On 9 Mar 2016, at 5:18 PM, Chris Belle <cb1963 at sbcglobal.net> wrote:
>>>
>>> Hey Jamie,
>>> You are right, I am not the top dog developer of the pack,
>>> but I have used both hsc, and ahk and also hotspots from window-eyes
>>> and golden cursor and I can see the differences in each method.
>>> You definitely want that top level window going on,
>>> hsc can slice it any way you want to,
>>> with lots of criteria for determining cordinates, but the most 
>>> common used is the plug-in name, or immediate application name.
>>> And yes, doing it with the plug in a separate windows is best.
>>> When I did my spots for golden cursor I was racking my brain on how 
>>> to make the plug express in a separate window, I have done this 
>>> before as I made the ahk script for sfz a while back for reaper, but 
>>> I'll be darned if I can remember where that setting is, maybe it's 
>>> not there anymore.\
>>> I look in vst and compatibility, and plug-ins,
>>> but I can't find that open plug in a separate process anymore.
>>> Huh, it's hell getting old,
>>> but anyway, I did the best I could,
>>> but the way I did it depends on the limits of golden cursor which 
>>> can only ping the main application,
>>> so if the plug moves around, or changes some how, it won't account 
>>> for that.
>>> But Rome wasn't built in a day,
>>> we got to start someplace right?
>>> I think a good first move would be to have that top level window 
>>> name and I think it will be easier for folks to remember cordinates 
>>> when programming instead of fractions, that seems to be the way 
>>> everyone else does it,
>>> going by the top left corner,
>>> of the window, other wise, you'd have things like what the heck 600 
>>> by 800, and I'm at 125,136 what the heck is the fraction for that?
>>> Maybe some sort of way to auto-resize,
>>> anyway, people with higher pay grades than me can figure out the 
>>> inner gears of this stuf,
>>> I can squeeze the oil can, and turn a screw driver, and wipe a rag, 
>>> but someone else will have to build the engine from the whole frame 
>>> 'grin'.
>>> Thank you for your attention to this, one final thought,
>>> I think hsc and ahk do searches by color and such from matching 
>>> patterns, and they set restrictinss on how far to search up and 
>>> down, it can get terribly complicated,
>>> but for us just having basic find me here in this location will be a 
>>> great start.
>>>
>>>
>>>> On 3/8/2016 10:49 PM, 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
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>>
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp

-- 
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: jamie at nvaccess.org