[Rwp] Plug-in hot spots

[James Teh]

That's just the thing. Your parent, top level, whatever you're calling 
it isn't actually the plug-in window. The plug-in window is several 
windows beneath that. If you were dealing with the plug-in window 
itself, you wouldn't have to worry about bridging or not bridging. For 
the most part, the plug-in window usually doesn't have a name at all. 
The window you're talking about is generated by Sonar/REAPER, not the 
plug-in.


On 9/03/2016 9:27 PM, Chris Belle wrote:
> Right that's how sonar does it with ahk and hsc.
> the only time you want to use the parent window name is if you were 
> doing sets for botgh daw's and the plug-in windows were named the same.
> I was meaning the closest title or plug oin window when I said top 
> level window,
> on top of the tree.
> But I'll start saying child and parent.
> I get confused, there are so many types of windows, for instance 
> window-eyes uses overlap, and focussed,
> and current and
> on and on,
> jaws kind of does that too, along with home row and other stuff,
> but i understand parent and child.
> It's just different terminology but we're talking about boxes inside 
> of boxes,
> and we want to take the smallest box outside of the big box so we can 
> root around inside it and see what's in it.
> right now with my set-up reaper isn't cooperating, the window is 
> opening up I can use object nav and see the title window of say 
> sforzando or dimension pro,
> but it is incdeed opening up inside the fx window.
> So I need to figure out how to get it to fly outside.
> and I don't have those controls where I remember them being.
>
>
> On 3/9/2016 5:15 AM, James Teh wrote:
>> Actually, every plug-in renders at least one real "window" (or HWND) 
>> according to Windows. The problem is that many plug-ins just draw 
>> only into this single window. REAPER, Sonar, etc. don't do any 
>> interpretation at all; they just provide a parent window in which the 
>> plug-in can create its own windows. The reason coordinates are 
>> different in Sonar and REAPER is that coordinates in hot spot sets 
>> are being based off the top level window, which is, for example, the 
>> REAPER FX Chain dialog, the Sonar FX window, etc. I'm suggesting that 
>> they could instead be based on the plug-in window *beneath* that top 
>> level window, which would mean they're the same for every single DAW.
>>
>> Jamie
>>
>> On 9/03/2016 9:01 PM, Alan wrote:
>>> If I am not wrong, James, the bridge window is like a container for 
>>> non standar controls deffined by each plug in. However, it is not a 
>>> real window, but a kind of generated layout, so reaper, sonar or any 
>>> daw makes is own interpretation, that is the reason behind the need 
>>> of a different set of hotkeys for each daw. the window on screen is 
>>> not a real window according to the windows operating sistem api, so 
>>> you cannot access programatically to its properties.
>>>
>>>
>>> Enviado desde mi iPhone
>>>
>>>> El 9 mar 2016, a las 11:39, Chris Belle <cb1963 at sbcglobal.net> 
>>>> escribió:
>>>>
>>>> Here's my thinking.
>>>> If there's a compelling reason to go to fractions then we should, 
>>>> but right now jaws and window-eyes use cordinates which you can 
>>>> easily look at and translate say you want to re-produce
>>>> the hard work
>>>> of an hsc guy,k you can look in the file and say ok, the load 
>>>> button for sfz is 193,86
>>>> relative to the child window cordinates.
>>>> So that's easy to do, and it doesn't seem child windows resize that 
>>>> much or if they do those cordinates seem to always work,
>>>> maybe they stay relatively the same in ahk and hsc,
>>>> that no matter how the windows shrink or grow the cordinate amounts 
>>>> stay the same.
>>>> At least it seems to do so in sonar.
>>>> I don't know how they're pulling this trick off,
>>>> because I change display sizes and it doesn't usually break the hsc 
>>>> sets.
>>>> But if it does, then the bottom number seems to be more critical,
>>>> like 1024 by 768
>>>> if you change the 768 it breaks more hsc sets.
>>>> But that's the whole screen, the numbers of pixels across and down 
>>>> a child window seem to stay the same.
>>>> Anway it's easy to see what been done, and if we stay compatible 
>>>> with other tools doing this already, then we can share a lot more 
>>>> and not re-envent the wheel, unless there's a good reason to do so.
>>>> Just thoughts,
>>>> both jaws and window-eyes can use cordinate related to other 
>>>> windows than just the child window,
>>>> and maybe we could take advantage of NVDA's object nav and use 
>>>> container edges when they're available, and other stuff to zoom in 
>>>> on stuff even more.
>>>> With the jaws version there are lots of criteria you can use,
>>>> but like I said, even though I've done some hsc dev, the tool I am 
>>>> most familiar with is auto hot key.
>>>> It uses the title window you are working with,
>>>> and it can defferentiate between the parent and child windows
>>>> where it can fall down is when you need to drill down further than 
>>>> that and say you have different windows that open up in a child 
>>>> window say for instance sessindrummer 3 has a drumkit page and
>>>> a mixer page, but both have the same title window.
>>>> I hacked around it in autohotkey,
>>>> which can use hot strings and so doesn't limit the number of 
>>>> hotkeys you can use,
>>>> but I ran out of hotkeys in the jaws vesion and tried to make 
>>>> another hsc set for the mixer window but I had to hard-wire 
>>>> manually loading that set since the title windows were the same.
>>>> Hsc has come a ways since i did that a few years ago, but being 
>>>> able to designate a certain conrol or string, or something to say, 
>>>> hey, this set of controls is active now, use this set of commands 
>>>> and ignore those  others,
>>>> I hope I'm making sense.
>>>>
>>>>
>>>>> On 3/9/2016 4:14 AM, 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
>>>> _______________________________________________
>>>> 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