Open SomeoneCalledRob opened 1 year ago
At some point, probably. It's just very low priority right now. The only reason to support AU is for Logic Pro on macOS. And AUv2 is a significantly older and much less flexible API than CLAP, or VST3 for that matter. Supporting AU means that plugins that opt in to AU support will need to have their functionality restricted to match AU's limitations, and it will also put more responsibility on the user's side. The big one being that plugins would need to enumerate all of their parameters in a linear order, manually adding tombstones whenever a parameter gets removed. Then there's also the fact that Apple previously deprecated and then, after a bunch of backlash, undeprecated AUv2. So there's no way to know what the future will look like.
Thanks for the reply.
Maybe AUv3 is an option, as that gives you both iOS and Logic?
It's not. And iOS is definitely way outside of NIH-plug's scope for the foreseeable future. AUv3 is a wrapper on top of AUv2 that doesn't have an easy to use C API (so interacting with it from Rust is even more difficult). And they're not even plugins in the traditional sense, they're always hosted in standalone processes. The only reason to use AUv3 to support iOS, outside of that there are only downsides. I have not yet spoken to a single audio developer who preferred supporting AUv3 over AUv2.
OK. Thanks.
It would be amazing to have this plugin running in Logic Pro.
In 2024, we have clap-wrapper which allows us to easily generate VST3, Standalone, and, most notably here, AUv2 versions from a .clap file! Therefore, we can take CLAP plugins output by nih-plug and turn them into AUv2 quite easily.
At the moment, it can only be used with CMake, but for the time being that will be sufficient for anyone trying to convert their nih-plug into an AUv2.
Here's the nih-plug gain example running as an AU in Logic Pro:
The CMakeLists.txt I used to achieve this this can be found here. I'm also sharing it here just to be sure:
cmake_minimum_required(VERSION 3.15)
project(gain) # <-- change me
# this CMakeLists.txt has a "gain_auv2" target that
# converts the "gain.clap" file into AUv2 plugin "gain.component".
# assumes the "gain.clap" file is located next to this CMakeLists.txt
set(CLAP_PLUGIN_PATH "${CMAKE_CURRENT_SOURCE_DIR}/gain.clap") # <-- change me
# the following lines are required to build AU SDK on macOS
set(CMAKE_CXX_STANDARD 17)
enable_language(OBJC)
enable_language(OBJCXX)
# ensure clap-wrapper lives as a submodule next to this CMakeLists.txt
# https://github.com/free-audio/clap-wrapper/
set(CLAP_WRAPPER_DOWNLOAD_DEPENDENCIES ON)
add_subdirectory(clap-wrapper)
# create AUv2 target
set(AUV2_TARGET ${PROJECT_NAME}_auv2)
add_library(${AUV2_TARGET} MODULE)
# use clap-wrapper to populate the AUv2 target
target_add_auv2_wrapper(
TARGET ${AUV2_TARGET}
MACOS_EMBEDDED_CLAP_LOCATION ${CLAP_PLUGIN_PATH}
# change all of the below
OUTPUT_NAME "gain"
BUNDLE_IDENTIFIER "com.yourcompany.gainclap"
BUNDLE_VERSION "1.0"
MANUFACTURER_NAME "Your Company"
MANUFACTURER_CODE "YuCu"
SUBTYPE_CODE "Gain"
INSTRUMENT_TYPE "aufx"
)
To use this, install CMake, create a folder, create the CMakeLists.txt
with the above (adjusted) contents, add your .clap
file and the clap-wrapper
repository next to it, and run:
mkdir build
cd build
cmake ..
cmake --build .
cd ..
@SomeoneCalledRob @wolterkam
@CrushedPixel thanks, this is great! it worked almost out of the box for me, just had to define CMAKE_OSX_DEPLOYMENT_TARGET
:
set(CMAKE_OSX_DEPLOYMENT_TARGET 11.0) # or whatever it is you're targeting
set(CMAKE_OSX_ARCHITECTURES "arm64;x86_64")
might also be something that you want to configure.
before notarisation it also seems to be necessary to sign the clap plugin bundle that's wrapped inside of the main plugin bundle.
EDIT: also noticed that auval wouldn't find the component after rebuilding when the build folder already exists; cleaning first seems to be required for some reason: cmake --build build --clean-first
Just curious: Will this framework be expanded to support AU at some point?