[Rwp] Plug-in hot spots
Chris Belle
cb1963 at sbcglobal.net
Wed Mar 9 12:46:58 EST 2016
Well, I've been experimenting.
I went back and revisited my work creating an autohotkey sfz file and I
installed reaper, and sure enough the bridging options showed up.
I guess you give that up when you run portable.
At any rate, I loaded my old stuff and it does work.
but it does not work with the bridge window.
and that's what everyone says who advised me,
Phil Muure, and Steve Spamer,
all those guys who have done hsc stuff for years all told me to put the
child window in a separate process.
but I have gotten some of my spots to work in a bridge window, like I
was saying about sonar platinum,
and being surprised that some of them actually worked.
so I could not get my old autohotkey thing to work at all in the bridged
window, I even took out the window criteria,
and even manually tried to find the cordinates, but it didn't work.
So I guess there's other stuff going on to complicate it, i don't know
why it works sometimes and other times doesn't, but I know my work I did
if I follow the separate process instructions sstill works with reaper.
and sfz now.
there's been discussion on list with GN luca and he's done some work I
think in bridged and non-bridged modes,
I don't know if he's settled on something or just takes it on a case by
case bassis, there might be some plugs that do better in bridged mode
and others need to be in their own windoww.
I need to do some more experimenting to see what's going on, but it's
nice to know something i did years ago still works with reaper today
'grin'.l
On 3/9/2016 6:19 AM, James Teh wrote:
> In theory (and I can't be absolutely certain of this), the window
> created by the VST itself should be identical regardless of the host.
> However, even when Sonar and REAPER open plug-ins in a dedicated top
> level window, they still have to put that plug-in *inside* their own
> window, bare as it might be. It's likely that this outer DAW window is
> different between hosts (e.g. it might have a thicker border or
> something), which would break any coordinates relative to it.
>
> I think the Sonar FX window is somewhat less populated than REAPER's
> FX Chain dialog because it opens every effect in a separate window. It
> does still have presets and stuff in it, but it's a *lot* less
> content. That might be why your coordinates were still able to work.
>
> One reason screen readers don't tend to use the Win32 terminology is
> that it's difficult for non-programmers to understand and it doesn't
> cover everything, particularly in modern apps. For example, NVDA users
> never deal with windows in the Win32 sense; everything is abstracted
> so we can use one set of terminology even for apps which have just a
> single window. You might be interested to know that Firefox, for
> example, has one single top level window most of the time (no child
> windows), even though it draws potentially thousands of controls.
>
> Anyway, I think this is probably getting ridiculously off-topic. Sorry
> for starting a flood; that wasn't my intent.
>
> Jamie
>
> On 9/03/2016 10:02 PM, Chris Belle wrote:
>> 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
>>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>
More information about the RWP
mailing list