[Rwp] Plug-in hot spots
Chris Belle
cb1963 at sbcglobal.net
Wed Mar 9 07:39:31 EST 2016
Hey Jamie, always glad when you explain things, I always learn something.
Ok, well, I'll continue to work with my plugs for reaper in the standard
mode they are in
now without trying
to make them open up in a separate process.
But explain one more thin what do you mean the f6 shows that window, do
you mean what ever plug-in is focused, or do you mean the fx window?
Because I thought you were already in the fx window when you hit f.
I am still a little fuzzy about reapers way of doing the actual fx
windows though I am totally comfortable with the shift p thing.
I have managed to muddle my way and make some spots with golden cursor,
but if I can hit f6 and focus the window I am working on each time that
would save a lot of hassle wen cllickin around and accidentally loosing
focus again and again 'grin'.
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