PopupMenu not showing on AUv3 plugin

Here’s a minimal example project: Click here

It’s basically the Projucer Audio Plugin template, really the only changes are in PluginEditor.h/.cpp.

When I run it as an AUv3 app extension in iOS GarageBand, the PopupMenu doesn’t show. It shows correctly on the AUv3 standalone.

1 Like

Yep. In GarageBand your plugin is running as a separate process, and its window is embedded in GarageBand. If you start trying to create other windows, like a menu, then that window belongs to a completely different app and can’t possibly appear in the GB process.

Thanks for the reply. So that’s why it doesn’t work…Is there any way, or a plan to make menus that work in AUv3 plugins? Or would it be best for me to make my own menu Component that isn’t a window?

You’d need to use sub-components within your editor window. PopupMenus aren’t so good for that, as they expect to be on the desktop, but perhaps if there’s demand for it, we could modify them to allow them to be given a parent Component to live inside.

PopupMenus and ComboBoxes in JUCE have needed to be fixed for plugins anyway… so this may be a good time to address the issue…



1 Like

i would also like the idea of having more controls on popups, or having them inside other components, while still keeping the scrolling and centering functionality

There is definitely a need for popup menus. How else would the user be able to select presets? Popups are definitely an essential part of any synth plugin.

See screenshots of Arturia iSem with popups inside of GarageBand as an AUv3 Plugin

As you see from the screenshots in Arturia, the popups are not real popups (i.e. separate native windows). They just draw a component on top of the main component. You could implement something like this with a ListBox in JUCE.

If work is done on PopupMenu, using a model class so we don’t have to compute the whole menu at construction would be great as well.

my 2 cents

OK. On the latest develop tip we’ve added support to “popup” a menu inside a parent component without the requirement of opening a separate window.

This can be done in two ways:

  1. via the the new withParentComponent PopupMenu::Options option. For example, creating a popup embedded in the top-level component could be done in the following way:

    menu.showMenuAsync (PopupMenu::Options().withParentComponent (target.getTopLevelComponent())
    .withTargetComponent (target), myCallback);

2) Override this option for all menus with a new LookAndFeel method:

  Component* getParentComponentForMenuOptions (const PopupMenu::Options& options);

For example, in an AUv3 plug-in this could be used in the following way:

class PopupMenuPluginAudioProcessorEditor  : public AudioProcessorEditor
       PopupMenuPluginAudioProcessorEditor (AudioProcessor& processor)
            : AudioProcessorEditor (processor)
           setLookAndFeel (&lf);
          setSize (300, 200);
     class ForcePopupsInParentWindow : public LookAndFeel_V2
         Component* getParentComponentForMenuOptions (const PopupMenu::Options& options) override
        #if JUCE_IOS
            if (PluginHostType::getPluginLoadedAs() == AudioProcessor::wrapperType_AudioUnitv3)
                 if (options.getParentComponent() == nullptr && options.getTargetComponent() != nullptr)
                     return options.getTargetComponent()->getTopLevelComponent();
           return LookAndFeel_V2::getParentComponentForMenuOptions (options);
     ForcePopupsInParentWindow lf;

Thanks so much guys…This was fast!

Also, great look on prioritizing AUv3 over AudioBus. Many of my users are requesting this more as the flexibility is definitely better.

I just wish iOS wouldn’t restrict us to that ugly 2048 × 670 with that big keyboard on the screen. It makes you have to create a new view just for it, but great work again guys!

Great! And I’m glad it’s so easy to use globally or on an individual basis.

It was necessary for me to remove the #if JUCE_IOS and #endif statements so this would fix a crash in OS X too.