"Show Automation Track" Cubase right-click menu

Hey everyone,

I noticed within Cubase all the stock plugins, as well as plugins from e.g. Meldaproductions, have right-click options on the parameters to “Show Automation Track” , or “Focus Quick Controls”, among others.

(Vague picture, had to outrun the screenshot tool haha)
image

I was wondering if anyone knows how they’ve implemented that. Is there a way to take control of the host to do stuff like that?

Take a look at AudioProcessorEditorHostContext::getContextMenuForParameter. Using the HostProvidedContextMenu you can display the host menu for any parameter, or get an equivalent juce::PopupMenu that can be customised.

Note that this feature isn’t supported in all plugin hosts or formats.

1 Like

Thank you!

Took me a couple hours but I got it working. :slight_smile:

I wonder why other plugin companies don’t use this context menu. It saves so much time in Cubase setting up the right automation lane.

PopupMenu’s in the context of plugins are becoming a liability due to changes in the way sandbox policies are being implemented by OS vendors - for example with AUv3, Plugins no longer have an easy way of gaining access to the host/caller window UI context, which is needed to attach the sub-window “PopupMenu” to a parent window for proper brokering by the native UI … this is broken by intent in AUv3 and requires a re-think by UI designers, imho.

So, be careful with putting too much into PopupMenu’s - better would be to have your own contextual UI elements for the info, in the end…

1 Like

Ah, that’s too bad.

Thanks for the explanation! I’ll be checking out how far I can go with my own context elements.

Just really love that 2-click automation lane :stuck_out_tongue:

in all daws i know you can just activate write mode of automations and move the parameter a bit in order to let the automation lane show up. and if there’s already automation on that parameter it will appear in the list of automations of that track somewhere. maybe that’s why the dropdown menu is not used a lot both by users and developers

1 Like

… yea you have a fair point. I really should just get “slapping the write button” into my system.

For some reason when sound designing I always go through the menus …

You can still use the standard PopupMenu; just make sure that it doesn’t get added to the desktop but rather to your AudioEditor component.

If you target AUv3, you won’t have much fun with PopupMenu’s… AUv3 sandboxing no longer provides the mechanism required to attach a sub-window to the parent window, and thus any PopupMenu you instantiate in the AudioEditor is going to ‘float’, unattached/associated with a parent window …

A PopupMenu is just a standard component, not a subwindow. If you provide your AudioEditor as the “target”, then it will simply add that PopupMenu to your main component as a child component and remove it, once the menu is no longer visible.

In the context of JUCE, yes - its just a component. But to the native windowing subsystem, popupmenus’ are subwindows and have to be bound to a parent in order for the windowing system to manage it properly - this was not working at some point in AUv3, where plugins do not generally have access to the host resources (because of sandbox/security requirements) - but it appears that there has been a fix for this found, and sub-windows are treated properly in the AUv3 context …