ProTools automation menu

Audio Plugins
21

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

2 Likes
22

Hi guys,

Bumping this up, this would really be super helpful

Thanks!

1 Like
23

Any feedback from the juce team about that?

1 Like
24

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 !

25

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?

26

+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.

27

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.

28

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.

29

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.)

30

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

31

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.

32

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.

??

33

The issue you’ll run into by adding these patches into the Component class is that you’re also blocking the editor and the content wrapper in JUCE’s AAX implementation from receiving events. See these methods:

The ContentWrapperComponent acts as a mouse listener to your AudioProcessorEditor, so that it can use getControlParameterIndex() to determine if the mouse event should be forwarded to Pro Tools for the shortcuts.

I believe that the workaround would actually have to be changing this logic in the wrapper so that if you’re ignoring the Pro Tools automation shortcuts then your AudioProcessorEditor isn’t allowed to receive those events, they simply get passed to the AAX_IViewContainer.

Our way of handling this all came about from a different issue… we had made custom widget types (sliders, labels, etc.) to override and extend some of JUCE’s default behaviours, and once we got to AAX being able to “ignore” the Pro Tools shortcuts was just a matter of adding the logic into our subclasses. This is where we block the shortcuts for all types of events: mouseDown(), mouseDrag(), mouseUp(), etc.

1 Like
34

Thanks again, Tony, this is very useful info. I don’t have a clear flowchart of where mouse events get passed around, and without that I guess I was bound to run into trouble when messing with an "internal"Mouse method in a base class like Component!

As I mentioned above in my first reply here to @ttg, I would rather see these modifier key shortcuts hard-wired into the AAX wrapper. It’s a feature that any dev making AAX plugs would want, and so it seems silly for each interested party to have to hack out a custom solution by modifying Juce’s mouse event system.

But for now, maybe I’ll look more into the approach you took, via custom widgets, which would allow me to check for modifier keys in mouseUp(), etc. I’ve already subclassed my Toggle component, inheriting from ToggleButton, but only for graphics purposes. When I tried to write my own mouseUp() in my subclass, I started by copying in the contents of Button::mouseUp – but that immediately produced errors because of the private members of Button that it needed to access. So it wasn’t going to be a quick fix, and I haven’t gone back to hacking at it yet.

35

Very welcome, always happy to help :slight_smile: I agree that this should probably be something in the wrapper… I do feel that making a plugin “platform agnostic” is the best approach, but unfortunately that’s not always feasible given DAW host behaviours and conventions

Unfortunately it seems the custom widget subclass is the best way to implement “intercepting” these events for now… I was trying out a method of having a “wrapper” component that holds the UI, and only passing on the mouse events if no modifiers were used. But obviously the lowest children have to be the ones first receiving mouse events in the framework, so you can’t use a “top down” approach of passing down only certain mouse events (even if you use setInterceptsMouseClicks()!)

One thing I will say:

Instead do something like:

void myCustomButton::mouseDown(const juce::MouseEvent &e)
{
    if (e.mods.getRawFlags() != AAX_SHORTCUT)
        return juce::Button::mouseDown(e);
}

Mose of the widget classes only have protected access to the mouse/keyboard event methods, so you can freely call those base class methods when you want the “default” behaviour!

1 Like
36

Whoa, you’re a lifesaver. I did not know that would work. I would have guessed that juce::Button::mouseDown(e) would behave like a static call, and so without the relevant data of the specific Button instance, it wouldn’t be useful. But it is very useful indeed!

37

You’ve raised a lot of concrete concerns.
Indeed the current AAX Wrapper JuceAAX_GUI makes it hard to implement something without a lot of refactor to JUCE.

So I’ve kept the less elegant ‘global flag’ patch. just because it’s a smaller patch and provides out-of-the-box support without special classes.

If you use your own parameter<>slider attachments you’ll need to add those nasty returns in your begin/end parameter changes.

1 Like
38

Its been a while and we have the same issue using JUCE 7 and PT 22.12.0.
I cant see this patch added to the master branch so is this still expected to be a manual work-around/patching process? Or has it been solved in another way since ?

39

It was never added to vanilla JUCE.
It’s still available on the Sound Radix JUCE fork.

It was tested by our QA for a few years now and seems to be working well for them (and our users of course).

1 Like