#1

Hello again, I’m curious as to how I would begin learning how to write an AudioUnit plugin. I’m a professional programmer in Ruby, with past experience in a variety of other languages (although my C is very rusty by now), so programming itself is not a problem. I’m just not sure what the best way to learn the build system, how to set up a project, and some good tutorials for developing both the interface and the algorithm implementations that might be useful in such a tool.

Where should I start and what build environment / toolkit / etc. would be most worth learning if I want to turn this into something more serious/professional in the future?

1 Like
#2

Unfortunately Apple’s AU documentation is a nightmare to get started with on its own. I would recommend starting with a friendly cross-platform layer like JUCE (also see its github) or WDL/iPlug.

Both of these frameworks are good routes to making professional work in the future. Both are oriented towards C++ because C++ is overwhelmingly the choice of audio programming professionals. You could look at some ADC Conference videos to get a feel for the current mainstream of audio developer culture.

6 Likes
#3

Hello, it could be worth taking a look at Plug’n’Script by Blue Cat Audio.

It’s not a complete solution like the suggestions above but it seems pretty great for testing out ideas quickly. I just picked it up yesterday after spending some time with the demo.

#4

Wow, WDL/iPlug looks really fantastic. JUCE did interest me from previous research, but their fees are rather high for something I don’t anticipate would earn me very much initially. I’ll try iPlug and see how far I get. My main concern is the UI - how does one “do” a UI in C++ for these sorts of projects? Mostly I need just the basics: knobs, text fields, dropdowns, and the like.

I’ve got my first project mocked up in Max, so the basic logic and functionality is working; it’s wiring that logical code up to some sort of UI and piping the MIDI / Audio in and out of it that I’m completely in the dark on.

#5

JUCE is the standard for most audio plug-in developers. There are a couple examples of iOS/Mac OS AUv3 somewhere on the apple developer webs as well but if you want to do VSTs as well, JUCE is the route to go.

As for UI in C++, JUCE pretty much has components like knobs, text fields, etc you can use to layout UI. However, they are far from nice graphics and you’ll have to figure that on your own. Good luck!

#6

Yeah, I’ve used JUCE and definitely found it very quick to get up and running, although I agree with @yun that aesthetically it leaves a little to be desired, unless you roll your own components. I was able to port my hardware firmware (previously running on Teensy) to JUCE in a day or so. Here’s the source in case it’s of interest https://github.com/cutlasses/GlitchDelayPlugin

I don’t have any experience on the other APIs mentioned, so can’t comment on those…

1 Like
#7

Perhaps of interest is this upcoming (free) course on writing audio plug-ins with juce:
https://www.kadenze.com/courses/intro-to-audio-plugin-design-and-development/info

5 Likes
#8

i’ll offer a friendly counterpoint to @randy and say that i’ve found the latest versions of AudioUnit samples (v3) to be not so bad

https://developer.apple.com/library/content/samplecode/AudioUnitV3Example/Introduction/Intro.html

(that is, if you’re really interested in AudioUnits particularly and not targeting multiple platforms.)

though, i really wish there was an updated version that replaced all the objc with swift, which is now quite doable and a pretty nice way to work (IMHO). if you’re used to macOS and iOS it’s painless, otherwise sure its a bit of a steep climb.

but yeah JUCE is fine and certainly a great place to start. there is of course a free license (shows a splash graphic) that is good for evaluating whether you like its style or not.

i’d contest that it is a “standard for most plugin developers” though. the “standard” as i know it is to make your DSP kernel totally agnostic and nicely parameterized, and wrap it in native or cross-platform SDKs as needed or permitted by time / business goals. (if for example you want to target LV2 then juce is still a nonstarter.)

every large, cross-platform project i’ve done with juce, without fail, ends up the same way: at some point, there are just too many platform-specific tweaks that need to be made; the project-generation stuff needs to be frozen and forked into multiple native projects. i’ve thus learned to actually stay well away from using JUCE calls in core functionality (confining it to UI and wrapper duties.)

(some tedious details)

for example, on the latest one i found that a) JUCE’s low-level iOS audio support is pretty wonky - you can’t select input routes, let alone use multiple routes, toggling pre-processing has weird side effects, &c - and b) its support for custom delegates is pretty broken and it was very hard to integrate a JUCE app with test/provisioning tools like Hockey or Testflight.

android was even worse.

it’s not really the fault of the JUCE team - i think they have a basically impossible task, even with ROLIs resources and licensing income. it’s kind of hubristic to promise to do everything for everyone everywhere.

(randy, i noticed you seem to be moving away from JUCE for madronalib as well.)

(and wow, i’m out of it and did not know about the forking of iplug away from WDL! interesting. can’t really comment more since i haven’t seriously used it. curious to know if it works out for you)

anyway my 2c

4 Likes
#9

I’m happy to hear that the more recent AU samples are better. I formed my opinion based on the state of things prior to this release you link to. If the examples actually build without forcing one to hunt down and curate a selection of additional mystery files, things have improved.

I don’t see Swift taking off on any non-Apple platforms, so it’s not for me except as a source of good ideas, of which it seems to have many.

I only JUCE only as a plugin wrapper around my core DSP library, basically as you are describing. It will be straightforward to use either iPlug or JUCE (or some combination) in the future—my plan is to take a step back, do a kind of “hello, world” plug with the latest version of madronalib, and a custom dial, and see which route causes the fewest headaches.

You can glean from Cycling’74s experience with Pluggo how difficult this task of maintaining a compatibility layer between core DSP and all the world’s plugin formats and hosts is. Confounding things greatly, some areas of functionality (view startup and host clock behavior come to mind) were not well specified in all the formats, leaving hosts to interpret them in different ways so there often has to be special-case code for one host or another.

I guess this is drifting off topic a bit, since the original poster doesn’t care about multiple platforms. So I’ll save my “plugins were done all wrong in the first place” rant.

3 Likes
#10

i still have nightmares about RTAS, and i want to hear that rant