AUv2 and AUv3 compatibility

MacOSX and iOS
1

Hi All,

With the release of iPadOS logic on the horizon I’ve been doing some testing of the current garageband situation.

If I load one of my plugins on iOS in garageband as an AUv3, save the project and export to MacOS garageband it will happily load the same plugins as AUv2 (what is installed on the machine). However, it doesn’t seem to be calling setStateInformation() - the plugin is reset to defaults.

Is this the expected behaviour? Is there anything I can do do resolve this? Will creating AUv3 on desktop fix this? - I would test but it always takes ages for logic to realise AUv3s have been removed when I accidentally build them so I’m hoping someone knows already before I do it!

Having said that… Maybe it will all change how it works with a release/update of logic!

Any thoughts/knowledge would be appreciated!

Cheers!

2 Likes
2

Thought I’d update this having done some experimenting as it will probably help others over the coming weeks and months.

setStateInformation() gets called when using AUv3 on macOS after transferring a project from iOS. Importantly this was done using an AUv3 built for Mac - not iOS running on Mac.

3

So to clarify what you tested/saw.

  • macOS AUv2 → iOS AUv3 → Instantiated;Restore State
  • iOS AUv3 → macOS AUv2 → Instantiated; Doesn’t restore state
  • iOS AUv3 → macOS AUv3 → Instantiated; Restore State

Is that right?

1 Like
4

To clarify

  • macOS AUv2 → iOS AUv3 → Impossible to test until logic pro is released tomorrow for iPad as GarageBand is only one way (iOS doesn’t have the full features)
  • macOS AUv3 → iOS AUv3 → Impossible to test yet (as above)
  • iOS AUv3 → macOS AUv2 → Instantiated; Doesn’t restore state
  • iOS AUv3 → macOS AUv3 → Instantiated; Restore State

David

1 Like
5

See above… But in addition, I would imagine that it will be the case going the other way however… It will swap a plugin in if it recognises the code but won’t try to get it to restore state.

6

OK. Thank you so much for testing and clarifying this.

7

Thought I would also list my findings about converting plugins for use as AUv3 on macOS as and when I find them. The first is to put this in LookAndFeel. The “#if JUCE_IOS” was previously required for iOS stuff to get popup menus to work. Seems the case on macOS swell.

    juce::Component* getParentComponentForMenuOptions (const juce::PopupMenu::Options& options) override
    {
#if JUCE_IOS
        if (options.getParentComponent() == nullptr && options.getTargetComponent() != nullptr)
            return options.getTargetComponent()->getTopLevelComponent();
#else
        if (juce::PluginHostType::getPluginLoadedAs() == juce::AudioProcessor::wrapperType_AudioUnitv3)
        {
            if (options.getParentComponent() == nullptr && options.getTargetComponent() != nullptr)
                return options.getTargetComponent()->getTopLevelComponent();
        }
#endif
        return LookAndFeel_V2::getParentComponentForMenuOptions (options);
    }
8

Thanks @DavidCNAntonia for starting the discussion on AUv2 vs AUv3 compatibility.

** iOS AUv3 → macOS AUv2 → Instantiated; Doesn’t restore state*

Does anyone know if this is a JUCE issue or a Logic issue?

9

Related observation: it seems AUv3 in Logic always runs inside a sandbox even if the corresponding main app doesn’t have a sandbox enabled, which causes issues with VST, VST3 and AU plugin versions that do not run in sandboxes as it becomes difficult to share preset and user patches among them… Has anyone observed this as well?

10

I also wonder if we just can update our macOS plugins from AUv2 to AUv3 without having them sandboxed or other downsides for macOS users.

11

I don’t think you can avoid running in a sandbox but there are some “temporary exception” entitlements that you can use to get access to the macOS file system as before. How long those will remain available to use is anyone’s guess. It’s the kind of thing that sounds risky to lean on and deprecated from day one having temporary in the title!

These can be configured in the Projucer.

There are some things that we don’t have exceptions for, such as some types of network access which prevents some copy protection schemes from working.

2 Likes
12

Thanks for the info. I also think this sounds a bit risky and it takes away some flexibility and usability that desktop users expect.

@mfritze Any chance that Logic also loads the state of an AUv3 into an AUv2 plugin for iOS / macOS compatibility? Some plugin developers can’t or don’t want to support AUv3 in macOS because of restrictions and usability.

13

The sandbox is a strict requirement for all new applications. If you need access to more files, you need to declare it and ask the user for permission.

There is some wiggle room right now to not completely break backwards compatibility, but you can expect that this will be cleaned up in the future, because these issues are security nightmares.

14

Thanks for the clarification. This sounds like you have to make Logic X on macOS also sandboxed in the near future. Is there any schedule for this? Other DAW’s too?

15

Interesting, does this mean that the sandbox requirement will also be extended to applications outside the App-Store?

16

I can not make these statements. It helps as well, that I do not know the future…

But I look into the past and security increased over the years and seems to continue to be moved forward. That means: any “trick” that might work today, might break in the future. If a security researcher stumbles across something bad, it might even change very quickly.

So, in general: it does not help to work against or around best practices recommended by Apple. That might work for a bit, but can burn you at the most inopportune moment. We found a lot of these issues during the Apple Silicon transitions.

Also: with Pro-Apps now being available on the iPad, I can only assume that a lot of developers want to bring their AUs on iPads as well, because it is a new market to sell to. And to be compatible with iPadOS you need to be sandboxed, etc. anyway.

3 Likes
17

Can you maybe elaborate on how all this sandboxing would work on a practical level for instruments that have large libraries?

Our flagship product “NEXUS” currently has a library of around 227 GB of samples and presets. Around 30,000 of those are presets, the rest are samples that get loaded by the presets.

Ideally, we would need something where we can ask the user once for permission to access a certain “root” folder (the location of the content folder itself), and then we would have full read/write access inside that folder forever. We can’t ask the user every time a plugin is loaded or every time a preset is loaded. It has to be a one-and-done operation.

We have our own built-in browser with advanced searches, bookmarks, etc., and the user expects a single click on any preset to instantly load it. Asking the user every time is simply not a viable option.

Installing our content to a fixed “safe” location is not a viable option. Due to its size, most users want to install it onto an external drive.

We haven’t looked into sandboxing too deeply, but it’s becoming a concern.

18

Without adding my opinion about “the Apple” way, the scoped access should work (as long permissions won’t be removed).

Basically at least on iOS which hints about macOS “walled” approaches.

  • You ask for the native file browser.
  • User selects the folder they desire the allow the app to access onward.
  • The app should keep the security descriptor.

So now, any access should be done with the security scoped resource.

1 Like
19

See also:

20

Bumping this - we’re getting more and more customer requests to ensure that plugins running on macOS and iOS can restore plugin states and settings across platform (Garageband, Logic).

Before jumping into an investigation ourselves I was wondering if anyone else, or the JUCE team has started to look into this?

3 Likes