ProTools automation menu

Yep, that would work on mac. I'll try and remove the win hacks and give that to Jules.

Thanks, much appreciated! I hope Jules will accept the code. 

I got this to work for both Windows and OS X and Jules has included my changes with some slight modifictions in JUCE. In order to get this to work, you need to override the method getControlParameterIndex in AudioProcessorEditor to let Pro Tools know the parameter index that corresponds to the control that was clicked.

1 Like

Hi,

The suggested method is now implemented in JUCE so by overriding the functions it's simple to add this feature.

One thing I'm struggeling is how to avoid passing clicks when user hit the button/knob with the key combinations.

I've tried:

    if (m_isIgnoreCtrlCmdAltModifiers && modifiers.isCtrlDown() && modifiers.isAltDown() && modifiers.isCommandDown())
        return;

Overriding the clicked (const juce::ModifierKeys& modifiers) method,

 

What method do you use to avoid passing those clicks?

Is there any way how to call to this menu from my custom slider?

if (e.mods.isCtrlDown() && e.mods.isAltDown() && e.mods.isCommandDown()) 
    what_to_call()

Since we have a lot of custom ui I’ve thought the best way to resolve this would be adding a flag to avoid clicks with modifiers being intercepted.

Would be really nice if this could be add to JUCE / review by JUCE team and applied:

2 Likes

anything new regarding that?

It would be nice if the Juce Plug-in Demo implemented this, so that just by running it inside Pro Tools it would be apparent that this feature is supported.
I had to search the forum for a solid hour before getting to this info, and only because I was going to re-ask the same question since the Juce Plug-in Demo didn’t show the menu.

Yes, that’s a good idea - I’ll add it to the demo.

2 Likes

Hi guys,

Bumping this up, this would really be super helpful

Thanks!

1 Like

Any feedback from the juce team about that?

1 Like

Hey guys ! I was wondering how do you detect the Start key on Pro Tools + Windows to enable automation. I did a few unsuccessful tests, and I read that Pro Tools is supposed to prevent the key recognition so… Thanks in advance !

Was this added to the demo plugin? I don’t seem to be able to locate the code?
We get more and more requests to ensure that Pro Tools automation lanes work with a mouse click but it seems a bit of a challenge to do with the current JUCE framework?

+1

Although, since the current default behavior of passing clicks while engaging these automation modifier keys is both A) Pro Tools-specific and B) not imaginably desirable to a user, I’d rather see it hard-wired into the AAX wrapper, instead of it being a flaggable option in the general Component class.

That’s a good point. However, the rationale behind a global flag is to avoid different behavior across hosts. So for example someone on (or developer) might assign this key combination that won’t work on Pro Tools, and I expect that the actual plug-in behavior would be cross-host-platform as possible.

Likewise, a good point there.

Developers might assume that the plug-in behavior would be cross-DAW consistent – but of course they would be wrong in this case. Global flag or not, they are going to get different behavior across hosts. Although a dev might conceivably assign their own triple-modifier-key shortcut to a GUI component (although why??? but that’s another discussion), they obviously can’t stop Pro Tools from popping up that Automation Enable menu as well with that key combo. So as a user experience, it would be quite bad!

In other words – no dev who cares about Pro Tools support would put a triple-modifier-key shortcut in their plug-in anyways. But I guess the use of a global flag is good in that it highlights this issue for developers right from the start.

Two other things:

  1. The fix posted above by @ttg would block passing the click for the triple-modifier key shortcut (for enable automation). But it wouldn’t block passing the click for the CTRL+CMD (on Mac) shortcut, which automatically selects the respective automation lane in the track view. Correct?

  2. In further testing, I’m realizing that I’m only having this issue with the toggle switch components in my GUI. The Slider components are already properly ignoring the mouse action, when either modifier key shortcut is being used.

    Under normal (non-modifier key) use, the toggles respond on mouseUp, while the Sliders respond on mouseDown. I’m curious as to why the Sliders already “properly ignore” mouse actions with modifier keys, and the toggles don’t. Will dive in further later.

    My toggle switch components are a Toggle class I created, inheriting from ToggleButton. I need to take a closer look at my class to see if I should fill in more of the mouse event handling methods. (The Sliders in my GUI are standard issue JUCE Sliders with a custom look-and-feel applied.)

I tried applying the “global flag” patch that @ttg posted above, and it worked. Then I modified it, to cover the other automation-related shortcut as well: CTRL+CMD click (on a Mac) to display the automation lane in the track view. So now the code I’m inserting right at the top of Component::internalMouseUp looks like this:

#ifdef IGNORE_MOUSE_WITH_PRO_TOOLS_AUTOMATION_MODIFIERS
    if (oldModifiers.isCommandDown() && oldModifiers.isCtrlDown()) return;
#endif

And now that “display automation” shortcut works, except that there’s a new bug introduced! When I use that shortcut on a Slider, it does change the display in the track view, but it also locks up that parameter and prevents it from responding to any automation data!

In order to free it from that frozen state, I have to wiggle the Slider with the mouse, and then it jumps back into responding to automation data. (This only affects the Sliders - the Toggles in my GUI do not get frozen in this manner.)

So, to recap: previously, the Sliders worked fine with the shortcut keys, and I was only having an issue with my Toggle class getting passed the extraneous clicks. Now, the Toggles are working as desired (yay), but the Sliders lock up on me (arg).

Any suggestions on how to move forward?

Before applying @ttg’s global flag patch, I attempted to override my Toggle class’s mouseUp method (to change click behavior for just that one component, rather than globally). I copied in the contents of Button::mouseUp for a starting point, but because of the private members (of Button) that it uses, that wasn’t going to work. Is that approach a dead end, or am I overlooking some possibility there?

Sincerely,
Stuck Inside of Pro Tools with the Automation Blues Again

I noticed you’re adding your patch to the internalMouseUp() only. If you’re using a SliderAttachment, then you will end up with an incorrect state of automation gesturing AFAIK.

Using the PT shortcuts, take this logic for example:

Your slider will end up beginning a gesture change and possibly even setting a new value, but then the mouse won’t end the gesture change because of the patch. When you wiggle the slider around to fix it both of these start and end callbacks are correctly made.

We’ve found in our plugins that you need to ignore mouse events with these PT shortcuts in all cases.

This is helpful Tony, thank you! Yes, I am indeed using a SliderAttachment. So, what you’re showing me is that because of the patch I applied, sliderDragEnded is never being called… yes that would be a problem, I see.

I’d had a similar thought, and so I tried adding this to the top of the Component::internalMouseDown method, guessing that blocking only the mouseUp part of the mouse gesture was what was getting me in trouble:

#ifdef IGNORE_MOUSE_WITH_PRO_TOOLS_AUTOMATION_MODIFIERS
    auto mods = source.getCurrentModifiers();
    if (mods.isCommandDown() && mods.isCtrlDown())
    {
        DBG ("internalMouseDown thwarted!");
        return;
    }
#endif

Problem was, that then Pro Tools wasn’t recognizing the clicks at all when the modifier keys were held down - so the shortcuts weren’t engaging at all.

Now, granted, that’s not ignoring the mouse events in all cases, as you recommend doing. But if ignoring the mouseDown breaks the shortcut, then that seems like a non-starter.

??