-
-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Audio Unit support in the future? #63
Comments
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. |
Just curious: Will this framework be expanded to support AU at some point?
The text was updated successfully, but these errors were encountered: