Shortcut stolen by m1-monitor & m1-panner

[himwho]

Ctrl+Option+Command+Click seems to be stolen from m1-panner and m1-monitor

shortcut that gives you a quick option to enable automation on a parameter of a plugin

[himwho]

Yes. The main reason is that both m1-panner and m1-monitor present the whole interactive UI as one Murka/OpenGL component, so AAX/Pro Tools cannot tell which parameter is under the mouse.

That means Pro Tools sees “generic plugin surface,” not “this is the azimuth knob” or “this is the diverge control,” so host-level modified-click behavior can’t be applied correctly. This would affect both m1-panner and m1-monitor because they share the same Murka/JUCE structure.

The likely root cause is not just “a shortcut key is stolen.” It’s more specifically that host parameter hit-testing is missing for these custom-drawn controls.

Best fix
The robust fix is to give the host parameter-addressable components again. Practically, that means one of these:
Add lightweight JUCE child components over each automatable Murka control and override getControlParameterIndex() to map those components to parameter indices.
Migrate the important automatable controls to real JUCE controls, which gives host mapping more naturally.
For compound surfaces like the panner reticle, create separate invisible hit regions for the specific host-automatable parts, though that is trickier because one interaction can drive multiple parameters.

Important caveat
For controls like the panner reticle, one click/drag can affect more than one parameter at once. AAX’s getControlParameterIndex(Component&) model is fundamentally “one component -> one parameter,” so that particular control may never map perfectly without splitting it into separate host-hit regions.

[himwho]

put on hold until we finalize moving from murka to native opengl