Testing in Logic Pro

Audio Plugins
1

Hi all,

I’ve been having some trouble testing my plugins in Logic Pro. My users claim that they haven’t experienced any of these issues (and they would be pretty catastrophic issues, so I’m guessing I’d hear about them), so this seems to specifically be a problem with building and running the plugins on my own machine. AUs and Logic are a bit of a mystery to me, so I’m hoping someone could help shed some light on things.

My plugins pass auval and can be found/opened by Logic, however, they all behave strangely. Here are the issues I noticed relatively immediately:

  1. My plugins plugin doesn’t see the current auth status and says it unauthenticated. In every other DAW, auth status is found and shared between DAWs.
  2. The plugin seems unable to connect to the network. I tried to manually auth it in Logic, but it claims it can’t reach the server (as if your computer were disconnected to the internet).
  3. The plugin’s editor doesn’t render correctly. It renders with about 40% extra blank space around it.
  4. Some UI elements are totally non-functional, such as ComboBoxes.

Screenshot 2024-10-08 at 3.27.26 PM
Screenshot 2024-10-08 at 3.27.26 PM1169×988 93.7 KB

For at least #1 and #2, there seems to be some sort of sandboxing issue going on? As I said before, my users don’t encounter this issue, though, so perhaps its an issue with self-signing and running a plugin on the same machine? I tried signing in Xcode (setting “Automatically manage signing” for the AU target), but no dice. I haven’t set any “App Sandbox Options” in Projucer either (e.g. Network access or File access) since I don’t want to change the end user experience, which is apparently fine.

For the UI stuff, I don’t really have a clue what the issue is, but I can’t set up a FileLogger and try to get some logs going until I figure out how to get the plugin file access.

I’m running Logic Pro 11.0.1 on macOS Sonoma 14.7, though I’ve experienced this on earlier versions of Logic/macOS as well.

2

1/2 seems to be related to sandbox (I haven’t used network connections).
3 not sure about it.
4 maybe you can provide the popup-menu with a parent component, like this (in LAF):

juce::PopupMenu::Options getOptionsForComboBoxPopupMenu(juce::ComboBox &box, juce::Label &label) override {
    return option.withParentComponent(box.getTopLevelComponent()->getChildComponent(0))
            .withTargetComponent(&box)
            .withItemThatMustBeVisible(box.getSelectedId())
            .withInitiallySelectedItem(box.getSelectedId())
            .withMinimumWidth(box.getWidth())
            .withMaximumNumColumns(1)
            .withStandardItemHeight(label.getHeight());
}

file access: I think you should at least get access to application data directory (where I store presets):

inline auto static const path =
    juce::File::getSpecialLocation(juce::File::userApplicationDataDirectory)
            .getChildFile("Audio")
            .getChildFile("Presets")
            .getChildFile(JucePlugin_Manufacturer)
            .getChildFile(JucePlugin_Name);
3

Thanks for the reply!

Regarding popup menus, I do something similar for iOS already - maybe I’ll relax the iOS-only aspect of the codeblock here:

    juce::Component* getParentComponentForMenuOptions (const juce::PopupMenu::Options& options) override
    {
#if JUCE_IOS
        if (topLevelComponent != nullptr)
            return topLevelComponent;
#endif
        // nb: This is the default behavior.
        return options.getParentComponent();
    }

Regarding file reading, I do something very similar, though I use Application Support rather than Audio… I wonder if this might be a mistake? However, I see a ton of plugins that I’ve bought storing settings in Application Support, which is why I did so, and almost none storing any info in Audio or Audio/Presets.

4

Regarding popup menus, I do something similar for iOS already - maybe I’ll relax the iOS-only aspect of the codeblock here

I have seen a discussion here about this issue. AFAIK, giving a parent component is always better.

However, I see a ton of plugins that I’ve bought storing settings in Application Support , which is why I did so, and almost none storing any info in Audio or Audio/Presets .

Cause I get paniced when I see tons of folders in Application Support :sweat_smile: TBH I don’t think there is a difference.

so this seems to specifically be a problem with building and running the plugins on my own machine

Perhaps you can build it with a private Github repo action and download it back to your machine. Then you can see whether the problem persists.

5

Logic Pro sandboxes plug-ins, but only on Apple Silicon. Logic Pro running on Intel Macs and also Logic running under the Rosetta emulator do not have the sandboxing of plug-ins.

6

Perhaps you can build it with a private Github repo action and download it back to your machine. Then you can see whether the problem persists.

Thanks for this suggestion - I ended up building a signed installer on a different machine and putting it back on my primary machine to install it as if I were an end user. This seems to have worked, and now the plugin is behaving as it should (including the UI… for unknown reasons) and can see the existing license on the hard drive.

Beyond just installing the plugin, I had to clear out all previous instances of it on my hard drive, thanks to auval scanning the entire drive. I’m used to doing this for AUv2s, but what was causing issues is that auval will also accept AUv3s and possibly even .apps that use AUv3s. Some documentation, if anybody else is having this issue:

  • Delete every .component instance on your hard drive (AUv2)
  • Delete every .appex instance (AUv3)
  • Delete every .app instance (which I’ve found uses AUv3 or v2 by default) if you build the plugin in standalone mode
  • Empty your trash
  • Remove cache: $ rm -rf ~/Library/Caches/AudioUnitCache
    and $ rm -rf ~/Library/Caches/com.apple.audiounits.cache
  • Kill auval: $ sudo killall -9 AudioComponentRegistrar
  • Check that the plugin is completely deleted via auval -a
  • Now finally install the signed version of the plugin.

You can use $ mdfind "kMDItemContentType == 'com.apple.application-bundle'" | grep <YOUR_PLUGIN_NAME> to find instances of AUv3s and apps using them. I think you can use $ mdfind "kMDItemContentType == 'com.apple.audio.unit' && kMDItemFSName == '*.component'" to find similar output for AUv2s. The .app’s were trickiest to find, since I found that Xcode cached a bunch of them over time.