VST (Virtual Studio Technology) The VST plug-in format was created in 1996 with the release of Cubase 3. Since then, it has become an industry standard and is compatible with most DAW’s. VST’s were initially only compatible with the Windows OS, but they are now compatible with Mac as well. Windows users: From within Studio One, navigate to the Options Locations, and select the VST Plugins tab. By default, Studio One will have C Program Files Vstplugins as the default location. You can also use the Add button to add custom locations. Designing Audio Effect Plug-Ins in C gives readers everything they need to know to create real-world, working plug-ins in the widely used C programming language. Beginning with the necessary theory behind audio signal processing, author Will Pirkle quickly gets into the heart of this implementation guide, with clearly-presented, previously. To my knowledge, C is the best programming language for creating VST plugins. The reason C works so well when creating VSTs is largely due to the frameworks and libraries available. The WDL-OL library makes C an attractive programming language for VST plugins because it.
So perhaps you’ve grown tired with all your synths and want to dive in and make your own. Or you’ve got a killer idea for a new slicer plugin with extra coolness. Or maybe you just want to kick the tires a bit and see how VST’s work from the inside. What should you learn?
Going non-native
How To Make Vst Plugins
I worked for many years in DAW plugins and DSP. C is definitely going to be your language of choice: many of the vendor APIs for plugins (VST and Avid, at least) are in C, so there'll be a minimum of C to write the plugin base. That being said, I strongly recommend JUCE. JUCE is a multi-platform C toolkit made for audio software.
Before talking about different programming languages, I’d like to mention that programming is hard. If you don’t have any previous experience writing code, then any inspiration you might have is likely to get burned away during hours of frustrating debugging. If your goal is to make a cool plugin, it’s important to realize that you don’t necessarily need to write code to do it. There are, in fact, numerous frameworks which will help you to create a plugin by using visual drag-and-drop techniques, including:
These frameworks allow one to design a plugin within a graphical environment and then export it as a plugin which can be used in your favorite sequencer. Each of the above programs differs a bit in their cost, supported platforms, and support plugin formats. But if you are just looking to have a specific type of plugin for your own music or experiment with synthesizer construction, this is probably the best starting point.
It’s important to note that lots of serious software has been programmed or prototyped in frameworks like these. Many beginner plugin coders scoff off non-native frameworks because they are not commercially viable option. However, it’s important to remember that software development takes a lot of time, and using a higher-level tool can be a great tool to test out your ideas. For example, most of the devices in Ableton Live were prototyped in Max (though not Live itself, as the story is sometimes retold).
Enter the code
So perhaps a non-native framework isn’t best for your project. Maybe you can’t find one that suits your needs or you have a programming itch you need to scratch. If you have previous experience with Java or C# (or conversely, don’t have any previous experience with C/C++), then you should check out these frameworks:
Although again, each of these frameworks has limitations for platforms or performance, they should be enough to get you up and running. Developing software in higher-level languages is significantly faster than lower-level languages like C/C++, the importance of which should not be underestimated if your time is limited.
Down to the next level
The next logical step down the abstraction layer is C++. If you don’t already know C++, I would advise at least trying some of the above frameworks and other languages first. Really. C++ is quite a frustrating language to deal with sometimes, and the complexity and primitive tools mean many hours of hard work just to get stuff working. This goes double (maybe even triple or quadruple) if you insist on having a GUI window for your plugin.
C# Vst
But enough beating around the bush, C++ is what it is. One strong advantage of C and C++ is that they are fast. Compiled C code is generally considered to be one of the fastest executing languages out there, thanks to the fact that modern compilers can optimize for all sorts of chips and under conditions which mere mortals could spend years learning themselves. That said, the speed tradeoff is not often necessary for most plugins.
Generally speaking, it’s better to develop software in higher-level languages and then gradually move to lower ones as the speed is needed. How will you know if the speed is needed? Well, start your development in a high-level language and go down as necessary. The algorithms which you develop in order to shape a plugin’s sound are much harder to develop than the actual code, and thus translating that code to lower languages is not as difficult as the initial cost of development.
Though I realize that this article may come across as a giant anti-C++ rant, I promise you that this is not my opinion. It’s just that most newcomers tend to underestimate the difficulty and time required to write good software in C++, and they jump in too eagerly and get burned out. So rather than bashing the language itself, I simply want to caution the reader not to underestimate the amount of time and energy required to write audio software in C++.
That said, many great plugin frameworks also exist for C++. My favorite of them is Juce. You might be wondering why a framework might be necessary if you are already doing C++, and the answer is that with Juce, a lot of stuff comes “for free”, including cross-platform support, GUI generator, etc. The Juce framework is incredibly sophisticated and mature, and it handles a lot of the plugin implementation details for you. Speaking as someone who has also developed plugin cross-platform frameworks, this is not a trivial task and one which will save you countless hours of busywork and let you focus on the fun parts of plugin development.
Juce is GPL’d, which means that if you want to use it in a commercial context you will need to pay for a license to do so. However, if your plugin is open-source, Juce is free for you to use, assuming that your plugin is also open-sourced. If you consider this to be a big disadvantage, read on.
Considering framework costs
In this article, I have linked to several plugin frameworks and toolkits, some free and some paid. It seems that many beginning developers are scared off by paid frameworks and tools, but they shouldn’t be. If you really need the functionality provided by a framework or tool, do the math to see if it’ll pay off.
Consider your hourly rate. What’s your hourly rate? Well, consider how much you make per month/year, and figure out what that is in hours. If you don’t have a 9-5 job, then just consider what you’d like to get paid for an 8-hour contracting gig. The number doesn’t need to be exact; you only need a ballpark figure here. Now consider the price of the software divided by your hourly rate. Can you write the same functionality yourself in roughly the same amount of time? If not, you should consider the fact that being cheap now will cost you serious money later. Yes, 800$ (for example) may seem like a lot, but you could just as easily burn 4x that amount of money in your time spent with the end result being a much worse product.
It used to be that programming was about being clever and smart with algorithms and such. Modern programming is more about leveraging the tools and frameworks out there and bringing them together to make a great product.
However, it is understandable that not everyone has the cash upfront to invest in those types of tools. If that’s the case, then start out open-source until you’ve built up a bit of a war chest, and then invest in good tools. Everybody’s gotta start somewhere!
No Juce for me, thanks
But back to the original topic at hand. If you decide that you want to go it alone, there are certainly ample resources for doing this as well. The VST and AU frameworks are not impossible to code with by hand, but definitely require a bit more patience. So take the next step and get your tools set up, and start programming!
In this post we’ll install the WDL-OL library and its dependencies. We will then run one of the demo projects to make sure everything’s working fine.
Most of this is also covered in the videos by Oli Larkin:
The following section is Mac-specific. The guide for Windows is below.
Setup on Mac OS X using Xcode 4
Before we can get started, we have to download and install a few things. This part is a little laborious, but you only have to do it once.
Prerequisites
- If you don’t have Xcode installed, download and install it.
- Download the VST3SDK. You will have to register for an account first.
- Download the Audio Tools for Xcode. In Xcode’s application menu, click Open Developer Tool → More Developer Tools… (or click here). Find Audio Tools for Xcode in the list, download and install it. There’s a different version for different OS X versions, make sure you get the right one.
- Download RtAudio (includes the ASIOSDK files we need).
- If you don’t have git, make sure you install it first. It’s worth it!
Downloading WDL-OL
Now open a Terminal. Type the following lines to create a new folder inside your home directory and go into it:
Let’s get WDL-OL:
You may want to copy & paste the last line. Don’t forget the dot at the end! It ensures that you’re using the same version of WDL‑OL that’s used for these tutorials. You should have a new subfolder called wdl-ol.
Adding the Dependencies
Go into ASIO_SDK and copy the .cpp/.h files from RtAudio’s include folder here. Unzip the VST3SDK, and copy the files aeffect.h and aeffectx.h from the folder pluginterfaces → vst2.x into WDL-OL’s VST_SDK subfolder. Apart from that, You only need the base/source, pluginterfaces and public.sdk/source folders for VST3. Copy them like this:
Note that you’ll have to create the public.sdk folder by hand. This is what your folder structure should look like:
Now open common.xcconfig (it should open in Xcode) and make the following changes:
You can also see that we’re going to use Mac OS X 10.5 as both BASE_SDK and MACOSX_DEPLOYMENT_TARGET. Music producers and especially recording studios are often very lazy about updating their operating system: They don’t need any new features, but having the studio disfunctional for a few days due to updating problems could cause big losses.
Actually, the deployment target is the version your users will need, but I prefer to set the base SDK to the same version as well.
The 10.5 SDK isn’t included with Xcode 4. If you already have it installed, skip to Running the Example Project. If you don’t have it, read on:
Installing the 10.5 SDK
To get the 10.5 SDK, you need to download Xcode 3.2.6. Once you have it downloaded, mount the .dmg file, open Terminal.app and enter:
A Finder window will open and there will be a file called MacOSX10.5.pkg. Double-click it. If you’re using OS X 10.8 or later, it’ll show a message saying that it can’t install software from an unidentified developer. In that case, right-click the file, choose Open in the menu, and confirm that you really want to install the software. When installing, choose change install location and option-click on the drive you want to install to, so that you can specify a folder. Install it to the Downloads folder inside your user folder, for example.
After that’s done, you’ll have a new folder called MacOSX10.5.sdk in the location you selected. In Terminal.app, type:
Again, a Finder window will open. Drag the MacOSX10.5.sdk folder in there. After restarting Xcode, you should now have the old SDK available in Xcode 4. Make sure you keep the MacOSX10.5.pkg around somewhere: If you update Xcode to a newer version, you’ll probably have to do this step again.
If you have any problems installing the 10.5 SDK, please leave a comment and I’ll be happy to help.
Running the Example Project
Back in your terminal, go to the examples folder:
Run the duplicate script to create your first plugin (replace YourName with your name):
You will notice that there’s a new folder MyFirstPlugin. Go into it and open MyFirstPlugin.xcodeproj. Select the APP Target:
Now there’s a small bug in WDL-OL where the standalone app doesn’t output any sound unless you choose a different audio input. Fortunately that’s easy to fix: In Xcode’s project navigator, open Other Sources → OSX App Wrapper → app_main.h. Change line 34 (the one with #define DEFAULT_INPUT_DEV) to this:
Click Run. You will get a few linker errors:
These are easy to fix. Go to your project’s build setting (make sure you select your project, not a specific target) and set the value for Implicitly Link Objective-C Runtime Support to No:
Click Run again. After a few seconds, you should see your first plugin run as a standalone app:
Writing Vst Plugins
Validating the AudioUnit version without Logic
If you don’t own Logic, you can use Apple’s free auval tool to check whether your plugin’s AU version is working correctly. Make sure you’ve successfully built the AU target, open a Terminal and enter:
It should output a line similar to this one:
If it doesn’t give any output, try this.
Troubleshooting
If Logic (or auval) doesn’t find the AU version (and other hosts like REAPER see it): Go into the Build Settings, and make sure that the AU target is selected in the upper left. Search for “active arch”, and the list should only show one entry: Build Active Architecture Only, which has the value: <Multiple Values>. Change that to No. This way, 32- and 64-Bit will be compiled even in Debug mode. After that, run Product → Clean (Cmd+Shift+K), build again and it should work.
Setup on Windows using Visual C++ 2010 Express
First, install Visual C++ 2010 Express. Visual Studio 2012 has been reported to work, but I can’t test it on my system. After that, install Git for Windows, using the default settings. I used version 1.8.4. Run Start → Program Files → Git → Git Bash. A terminal window will open. In that window, run the following commands:
To paste into the window, right-click the title bar and chosse Edit → Paste:
Now copy all the VST2/VST3/ASIOSDK files into the right folders, as described above. Install Python using the default settings. I used version 2.7.5.
To be able to build VST3 plugins, we have to create the VST3 folder. Run this command in the terminal:
Now (in the terminal), navigate to the IPlugExamples subfolder:
Run the duplicate script using the Python you just installed:
You’ll get a new folder MyFirstPlugin. Go into it and open MyFirstPlugin.sln. Ignore the warning, it just means that you can’t compile AAX and TDM formats. In the project explorer on the left, make sure MyFirstPlugin-app is shown bold:
If it isn’t, right-click it and choose Set as StartUp Project. Now press the F5 key, and you should see a window like this:
Lovely, right?
Troubleshooting
If you get a fatal error LNK1123 when building, you may have to disable incremental linking: Right-click the MyFirstPlugin-app project, click Properties and go to Configuration Properties → Linker (General) → Enable Incremental Linking → “No (/INCREMENTAL:NO)”.
If that doesn’t solve it, try installing Visual Studio 2010 SP1. You may also want the Compiler Update to get 64-Bit support.
If you get warnings that CreatePackage.bat […] exited with code 1, don’t worry about it (unless you want to build an AAX plugin). The warning just means that the AAXSDK isn’t there.
The warning Cannot open include file: ‘ForcedInclude.h’: No such file or directory means that the RTASSDK wasn’t found. If you’re not trying to build RTAS, you can ignore this.
If you have any other problems, feel free to leave a comment! Next time we’ll examine the code.