[Rwp] Plug-in hot spots

[Chris Belle]

Ok, I think I get it.
At least some what.
'grin'.

I am used to sonar
opening up windows in a separate process,
but for what it's worth I noticed that in sonar platinum when I was 
testing with John some of my ahk stuf still worked even though the 
windows were showing up inside sonar's main window.
So the cordinates were obviously the same relatively speaking.
Now as far as making the same stuff work in sonar and  reaper,
do the vst plug in windows express themselves exactly the same way?
I thought we had a problem with that, otherwise the devs would have done 
reaper easily, I think there is some differences.
I do get the main point though,
no matter how the plug-in window is express,
we want to use  it as the reference, whether it's tucked inside the main 
app window, or by itself,
ok, I'm going to go sit in the corner now and play with my blocks and 
suck my thumb, ha.
This is crazy stuff indeed, but some how I've managed to make some stuff 
work over the years for myself and others,
if only everybody use the same terminology and
if only these screen reader universes weren't in their own separate 
universes,
and there was more cross polination.
I was on the beta team for helping with hotspot for window-eyes,
and they refer to their windows  one way, while jaws has it's own way,
and NVDA has it's own way,
there is a common set of rules I'm sure because it's all on the same 
operating system, and those have to be a given,
we are very fortunate to have Jim with us as well,
you and him understand what's going on under the hood,
where as the rest of us just get a glimmer now and again,
but there are some pretty smart folks around here,
anyone doing reaper is already a bit ahead of the game I think,
or at least has the spirit of hey, I can pick up a hammer and bang a 
nail instead of having automatic everything,
anyway, autohot key makes things simple by refering to the parent and 
child windows,
so I guess that's why I took to it,
but ikt seems like there were time
when the childwindow I wanted was inside the parent window that it 
couldn't find it.
so go figure,
I'm just trying ti nuddle my way through this ha.
Thanks for your patience in trying to explain.



On 3/9/2016 5:39 AM, James Teh wrote:
> Yes, you *can* set them to appear in a separate window, but that 
> causes awkwardness when switching between plug-ins in the chain; one 
> has to fiddle with alt+tab, etc. My point was that you shouldn't have 
> to... and if spots were defined based on the plug-in window (not the 
> top level window), it shouldn't matter. It'd also mean you could 
> define one set of spots and have them work in both Sonar and REAPER 
> without any offset madness. Even when you're dealing with bridging, 
> you're actually defining coordinates relative to the bridge container 
> window, not the plug-in window itself.
>
> Let me try to explain this another way. Each plug-in can create one or 
> more windows. When you open the effects in Sonar or REAPER, the DAW 
> creates its own window, whether that be the FX chain or the bridge 
> container. It then tells the plug-in that it can create its own 
> windows somewhere beneath the DAW window. In the case of REAPER's FX 
> Chain dialog, this is actually several levels deep. In the case of 
> bridging, the bridge container contains very little, which is why 
> spotting seems more reliable there. The point is that it is the 
> plug-in window that you want to be basing your coordinates off, not 
> the DAW window. And again, the plug-in window is beneath the top level 
> window, maybe even several levels beneath.
>
> FYI, a top level window isn't a child window; it's at the "top level", 
> meaning it has no parents. Most (but not all) top level windows are in 
> the alt+tab order. An application's main window is a top level window, 
> but it can also have other top level windows; e.g. dialogs, etc. To 
> make things more confusing, while top level windows can't have 
> parents, they can have an owner. Top level windows in an application 
> are usually "owned" by the main application window. And to make things 
> even more confusing, Windows has this function called GetParent which 
> actually does give you the owner window if you call it on a top level 
> window, even though it's not a parent strictly speaking. Clear as mud?
>
> Anyway, I fear this is going around in circles and it seems I'm not 
> able to get my point across. That's probably largely because this 
> whole situation is pretty confusing and I'm starting to realise you 
> need a pretty solid understanding of the way Win32 works to even grasp 
> it. That in itself is a problem because we can't expect people using 
> HSC, AHK or whatever to understand the nastiness of Win32; that would 
> somewhat defeat the point. I think the answer to my question is simply 
> that no one does what I'm suggesting because it's just too damned hard.
>
> On 9/03/2016 9:21 PM, Chris Belle wrote:
>> But you can set them to be real windows.
>> Because tools like hsc   and autohotkey
>> treat them as such when they can be made to open up in separate windows.
>> In sonar they default that way,
>> at least in 8.5.3 but in later versions of sonar the last time I 
>> looked, they were showing up inside
>> the parent window, I think I'll say child and parent from now on, 
>> because
>> that's already caused some confusion, I understand that terminology 
>> and it's what autohotkey uses, a tree to me meaks top level is a 
>> child window and the trunk is the parent the main application, and I 
>> think that's how snowman does his hsc terminology, correct me Jim if 
>> I'm wrong,
>> but we all agree the ideal is to have the window we are working with 
>> show up in a separate
>> tab order so we can ping it and separate it out.
>> When the plug is crammed inside the parent window, it's part of the 
>> same parent window and is harder to work with.
>> right now, all my plugs are showing up this way.
>> in reaper.
>> I think I may have to install reaper as non portable to get that no 
>> bridge
>> separate process.
>>
>> On 3/9/2016 5:01 AM, 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
>