Auv3 App with separate static Standalone UI

MacOSX and iOS
1

Hi there,
in the process of releasing an Auv3 effect plugin, with an iPhone/iPad standalone version
I want the Standalone version to be just a static page with a logo and some text telling the user to open an AuV3 host to use the effect (and maybe a manual/link to website).

I see that in case of projucer plugin project (standalone), everything wrapping the plugin processor is managed automatically by the AudioPluginClient Module that creates a main function + fires an audio/midi engine + instantiates a mini plugin host.

In the case of having a static page for a standalone I think this is overkill, also because I need audio permissions that I probably could skip having, since for Auv3 is probably the host that acquires the permissions.

So I’m thinking of 2 strategies….

(1)

  • create a separate standalone juce app, non-audio simple UI component hosting what I need to show the user
  • make an iOS exporter for this app & build it
  • bundle the App + the Auv3 plugin build (I guess they must have the same name?) locally or on ItunesConnect and publish as one app (never done before, if you think this is :skull_and_crossbones: please drop me a line :grinning:)

(2)

  • modify the Audio plugin client module (maybe make it locally copied on the project)
  • bend the Juce AudioPluginClient StandaloneFilterWindow to My will : no audio engine - no createFilterWindow just a happy UI component, probably linked to the module with another external function (i.e. extern Component JUCE_CALLTYPE createStandaloneLandingPage() in place of the classic createFilterWindow)

In a desert Island I would err towards (2)

Has anyone gone through this? Any hints ? Even if you haven’t, what’s your opinion?

Thanks!

1 Like
2

#1 will sort of work, but is very difficult. Only recommended if you’re bundling multiple plugins in a single app (e.g. Bram Bos’ Rozeta suite.)

It is much easier to do a sort-of-#2. What you want to do is make local-to-your-project copies of the JUCE standalone wrapper, then modify them to taste (removing the plugin hosting wholesale, e.g.). Add the “use my own standalone app” to the preproc defs, and you’re good to go; this way you can stay entirely within JUCE.

The third option is to just make a simple standalone that does what you want, and script it to import the AUv3 you built with the JUCE project on build. Note you will have to pay very close attention to naming conventions for this to work. I’ve done both 2 and 3 multiple times, and I find #2 to be the easier. (I have my own standalone that I just add to the project and alter for context.)

The final note is that it is sometimes quite difficult to get standalones that just have a logo splash through Review, and once you do, you’re going to get a lot of one-star reviews and support requests complaining that the app hangs on the startup screen. Both Bram and I have very clear text that says something on the order of “congratulations, you have installed the AUv3. Use it in an AUv3 host” blah blah, and this has no effect on the support.

So I would suggest adding the manual, perhaps a video showing simple use cases, etc. As long as the standalone does something it’ll get past the Review drones, and hopefully the somewhat more explicate usage demo will mitigate some of the idiot support.

Hope this helps.

4 Likes
3

uuuh I totally skipped JUCE_USE_CUSTOM_PLUGIN_STANDALONE_APP thanks!!! :pray:
#2 makes a ton of sense now. Very good news not to have to heavily modify juce stuff but only your project.