The latest AUv3 demo from Apple (AUv3Filter) is based on Swift 5, which is not supported by my MAC/Xcode version.
Is there a macOS JUCE project (demo, tutorial, etc) that shows a complete AUv3 audio implementation?
By complete I mean something that shows both the containing app and app extension working together and they get built together in Xcode.
Fwiw, I’ve searched the JUCE site and didn’t see one. There are some old forum posts on AUv3 but they seem to be based on user projects and generally end in failure.
If not, is a new version of JUCE coming out that will have direct support for this?
Thanks for the reply and yes, generating an AUv3 plugin is that easy! However, it’s not complete. Another way to put this point is that the “.appex” output from this process is not stand alone distributable.
An AUv3 plugin (.appex) does not simply load into the standard AUv2 plugin directories. Instead, it’s packaged with an app, that Apple calls a containing app. The containing app, which includes the AUv3 .appex plugin as part of it’s package content, is the distributable.
In Apple’s AUv3 scheme, at the completion of containing app’s installation, the containing app automatically runs and calls the AUv3 packaged plugin. This process somehow notifies the OS about the plugin and then it becomes available to other apps (plugin hosts/DAWs) for use.
So I’m looking for an example JUCE project that shows the complete containing app and extension as one build.
Apples latest AUv3 demo does this but it’s built on Swift 5 and I’m currently fighting a lot of issues to ‘downgrade’ that to Swift 4 in my version of Xcode. Beyond that, I’d rather just build my app in obj-C, which is what I’d expect a complete JUCE demo project to use.
I think this should automatically work if your project contains both a Standalone and an AUv3 target. The Standalone should contain the .appex, and should install it on first run. Have you tried this setup? If so, which part of the process is failing? Is the appex not included in the Standalone, or is it failing to install?
But to be clear, there’s really nothing failing, the JUCE AUv3 generated plugin builds successfully in Xcode, as an .appex.
My issue is the .appex output of is not stand alone distributable, i.e. loading it into the ‘standard plugin’ folders doesn’t work (by Apple intent).
Another way of explaining this is to say the .appex output (the AUv3 plugin), is located in the containing .app, which is in turn located in the standard Applications folder. The .appex can only be seen by selecting “Show Package Contents” on the AUv3 containing app. In this sense, an AUv3 plugin is loaded into the Applications folder.
Again, Apple’s latest AUv3 demo app does all of this but it’s based on Swift 5, which my setup has issues with. So, I’m hoping there’s a complete JUCE AUv3 equivalent project. I now doubt there is because it seems a new JUCE project type (AUv3 containing app) is needed.
In the Projucer, click the disclosure arrow in the “Plugin Formats” field and make sure that the “Standalone” format is selected, then resave and rebuild the Xcode project. You should find that the Standalone target is an .app which contains the .appex. Running the .app should install the .appex so that it can be used in plugin host applications.
The plugin and app are built from the same source. The plugin is loaded in a ‘standalone wrapper’ which handles window creation and audio device management. It’s also possible to supply your own wrapper code by defining the preprocessor flag JUCE_USE_CUSTOM_PLUGIN_STANDALONE_APP and copying/modifying the contents of juce_StandaloneFilterApp.cpp somewhere in your own project.
You can find it at modules/juce_audio_plugin_client/Standalone/juce_StandaloneFilterApp.cpp. On github you can use the “Go to file” button to locate any file by its name.
So if I have this right, to create a 100% duplicate wrapper (as a starting point) with modifiable source, the needed steps are:
(1) Add duplicate “wrapper.cpp” and “wrapper.h” file to my Xcode project under Source here:
(2) Define the “JUCE_USE…” flag in the new wrapper.h.
(3) Build the project.
Is this correct?
–
I’m wondering if naming conflicts would occur between the newly added wrapper source files and the original source files still under the JUCE standalone plugin client module.
I’m also wondering if any other config changes would be needed in Xcode.
I’ve now tried adding copies of the juce_StandaloneFilterApp source files to my project and it created a lot of errors. Some are simple, like include files not being found due to path name issues, others are deeper.
Given that the automatic generation of the standalone app works, would there be anything wrong with just modifying the actual source files in the Juce standalone module itself? (As matkat pointed out, they’re accessible in Xcode).
I’d be OK doing it this way as long as I can be certain no ‘unknown dependencies’ are introduced between main (wherever that is in the standalone plugin) and it’s call to juce_StandaloneFilterApp.
Just looking for some guidance here because the structure of this app doesn’t resemble the structure of the other apps JUCE generates, they all include a clearly defined main and are easy to trace through.
I’d strongly advise against modifying the JUCE sources, as this will make it more difficult for you to update to new JUCE versions in the future.
To supply a custom standalone wrapper, try the following:
Copy everything from inside the namespace juce block in juce_StandaloneFilterApp.cpp into a new .cpp.
Add the following at the top of the new file:
#include "juce_audio_devices/juce_audio_devices.h"
#include "juce_audio_plugin_client/juce_audio_plugin_client.h"
#include "juce_audio_utils/juce_audio_utils.h"
#include "juce_audio_plugin_client/Standalone/juce_StandaloneFilterWindow.h"
// Once the project is building, you should consider removing this line
// and manually adding namespace prefixes where necessary.
using namespace juce;
