[Rwp] Plug-in hot spots
Snowman
snowman at snowmanradio.com
Wed Mar 9 22:17:21 EST 2016
Yep, this is right. We're all on board with the smallest enclosing
container.
----- Original Message -----
From: "James Teh" <jamie at nvaccess.org>
To: "Reapers Without Peepers" <rwp at bluegrasspals.com>
Sent: Wednesday, March 09, 2016 4:30 AM
Subject: Re: [Rwp] Plug-in hot spots
>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
>
> _______________________________________________
> RWP mailing list
> RWP at bluegrasspals.com
> http://bluegrasspals.com/mailman/listinfo/rwp
>
More information about the RWP
mailing list