Komplete Kontrol not detected when not running Kontakt

[Timtam]

I've got a project running a Spitfire library that is not a Kontakt library but still running inside Komplete Kontrol. ReaHotkey however doesn't recognize Komplete Kontrol here and just doesn't show the overlay. I think it'd be useful to still have the usual Komplete Kontrol controls, like access to the menus and such, just so that we can load a new, different instrument that then again might be a Kontakt one.

[MatejGolian]

The solution I can think of is that when the correct plug-in is not automatically detected and the error overlay pops up the script would offer the option to choose the correct header/menu set manually. We can't automatically assume that we're in KK just because ImageSearch fails. But it would be good to know if this would lead to usable results. The LoadPluginHeader method in KontaktKompleteKontrol.ahk defines the respective overlays. To test things out, for now you just want to add the Komplete Kontrol menu button to the UnknownPluginHeader overlay. Just like always: UnknownPluginHeader.AddHotspotButton("Menu", 305, 68, CompensatePluginPointCoordinates, CompensatePluginPointCoordinates) Otherwise it should mostly just be a matter of utilizing AccessiblePluginMenu and overlay ChildControl replacing.

[Timtam]

Just for clarification, I don't get an error overlay or something either. I just get the typical Komplete Kontrol window and no sign from ReaHotkey whatsoever. I'll give your idea a spin after Christmas I think.

[MatejGolian]

I see. My idea would only work if ReaHotkey kicked in, but that does not seem to be the case here at all. If closing the FX window, reopening it again and pressing F6 does not make ReaHotkey active again, the problem could be that when you load up the Spitfire plug-in in KK and press f6 a control gets focused that does not have a class that we're matching against.

1. What control class does HotspotHelper return after you focus into KK with the Spitfire plug-in/instrument loaded up?
2. Can the Komplete Kontrol PNG still be found on the screen, for example by HotspotHelper?

[MatejGolian]

If the control class changes, but ImageSearch is still able to find the Komplete Kontrol PNG, we can load the Komplete Kontrol overlay via the GenericPlugin class after updating the code a little.

[MatejGolian]

I tested it with MusicLab RealGuitar and it's basically as I thought. The latest commit should now work with 3rd-party plug-ins reasonably well, although more commits may and likely will follow, because the code that deals with these kind of cases behaves a little differently than code for plugins in 'normal' mode now.

[MatejGolian]

Commit #23d4ca6 should now fully address this issue. On a related note, when you want to obtain the control class for a given plug-in, you always want the class that comes after "reaperPluginHostWrapProc1" in the list of Reaper controls which may not always. correspond to the currently focused control. This is because depending on situation, pressing F6 may actually focus a child control belonging to the loaded plug-in, as seems to be the case with plug-ins loaded inside of KK. Kontakt behaves exactly the same in KK, but the problem was not noticeable there, since KK and Kontakt have the same kind of control classes. @Timtam, if it now works for you, feel free to close this issue.

[Timtam]

It unfortunately doesn't work for me yet :(. I'm testing with Spitfire Hans Zimmer Strings by the way. I can find the KK image with the Hotspot Helper, but I don't get the overlay. It is pretty hard to debug control classes and everything btw, as the KK app seems to have a problem with something in Hotspot Helper, as whenever I call any action it'll freeze, forcing me to restart REAPER and re-open the project which takes some time. I basically get the Qt window that is KK, followed by 2 or 3 NI child windows, finishing with a JUCE window that is presumably HZStrings. Dunno if that helps though.

[MatejGolian]

I'm not sure, but perhaps some of the freezing can be attributed to Osara. My whole instance of Reaper can freeze when switching back to it from another window if the FX window containing KK with RealGuitar is open and that even with HotspotHelper or ReaHotkey turned off. So maybe it's something with the Osara code that focuses the last found window. I don't know what the problem could be and it's hard to figure out since I don't have that specific library. Otherwise yes, that Juce control is probably the 'Hans Zimmer' one. The 2 methods in the ReaHotkey class that you probably want to start playing with are GetPluginControl and InPluginControl. It could be enough to examine the latter one, since that calls the first one in a check too. The first one just detects the main control class, in this case it should always be the first 'QT' control. InPluginControl checks if the currently focused control is inside the main plugin control. Maybe this is where the problem could be. The way the script determines whether a given control is inside the main plugin is that the focused control can't come before the main plugin control in the list of controls. Than the script performs RegEx checks to make sure that the focused control is not one of the normal Reaper FX window controls, such as the Add button and so on. If those checks all pass, the script looks at the control dimensions and position and tries to tell whether the currently focused control is positioned inside the main plugin control. The way I usually do this, is that I place MsgBox or AccessibilityOverlay.Speak statements at the point where I want to check a value. For example before or after checks.

[MatejGolian]

You could start with checking if the below condition in InPluginControl is met. It's on line 127 in the ReaHotkey class. If PluginPosition > 0 And CheckPosition > 0 And PluginPosition <= CheckPosition {

[MatejGolian]

I removed the last bit that checks the control dimensions. When checking manually I was getting some crazily large values even with RealGuitar, but eventually that plug-in always worked. My guess is that some plug-ins either resize their windows correctly like RealGuitar once focused and so eventually pass the check, or they don't. Another possibility is that AHK is just not able to retrieve the correct information in certain cases. Either way, with that part of the code gone, things should now hopefully work for your plug-in as well.

[Timtam]

Yeah, now that the part that checks the window dimensions is gone, everything works as expected over here as well. Great work, thanks alot!