You are here

VST DIY

Creating Your Own Audio Plug-ins By Nick Storr
Published September 2009

There are lots of reasons why you might want to write your own VST plug‑ins. The learning curve can be steep, but there are development environments out there that can help. We take you through the options.

If you've ever used a modular synthesis environment, you'll know that they can expand your processing and synthesis horizons well beyond what you'll find in a DAW. Modular packages like Native Instruments' Reaktor or Plogue's Bidule, to name just two, offer a great deal of flexibility to put together weird and wonderful combinations of processes, to achieve results that would be difficult, if not impossible, with less flexible software. But if you want to share these concoctions with a friend or a colleague, or the public at large, things can get a little more complicated. If they own a copy of the same modular environment, you can trade a preset, but that limits your audience quite considerably, and becomes even more complicated if you've made use of any third‑party modules. And if you come up with something useful enough to sell commercially, the requirement for the end‑user to purchase an entire modular environment program just to use your creation is not likely to help your sales!

The 'Save As...' Programs

Enter the 'Save As...' packages. These are basically modular synthesis environments that allow you to export your creations as stand‑alone plug‑ins to be used in any VST host. One of the foundational players in the 'Save As...' movement is SynthEdit, from developer Jeff McClintock.A simple polyphonic synth prefab open in SynthEdit.A simple polyphonic synth prefab open in SynthEdit. This Windows program hit the market in pre‑release form around a decade ago, but the application's roots pre‑date the VST standard entirely. Jeff explains: "In the early '90s I was in a synth band called Krisis. We used an Atari ST for MIDI sequencing, but were frustrated because we only had two keyboards. I needed more synths. At that time I played a lot of arcade video games. I started programming a game called Defender for the Atari. In the game, each alien 'thought' for itself, independent of the others. The code naturally became very modular, and I saw a parallel with synth programming. Those factors together spawned SynthEdit.”

With the arrival of the VST plug‑in standard in the late '90s, Jeff saw a means to allow his modular creations to be used in third‑party applications. However, his approach differed from what some others were doing at the time. "When VST first came along, everyone was making VST conversions, trying to squeeze desktop applications into a plug‑in. I wanted SynthEdit to integrate somehow with Cubase, but I didn't want a synth‑building user interface squeezed into a tiny plug‑in window. You don't need it, anyhow. When you're jamming with a band, you need fast access to your presets: that's not the time to start tweaking patch cords. I took a different approach — synth editing and synth playing as two distinct activities.”

SynthMaker from Outsim, a more recent player on the 'Save As...' scene, had similar hobbyist beginnings.SynthMaker's slick GUI at work on a sample synth. The four panels near the top show progressive levels of detail as the project is zoomed in.SynthMaker's slick GUI at work on a sample synth. The four panels near the top show progressive levels of detail as the project is zoomed in. Outsim's Malcolm Barbour explains: "SynthMaker was originally conceived by Jorge Costa, who began it as a hobby project in early 2001. The idea was to create a general visual programming environment but initially apply it to the creation of sound. In 2004, I joined up with Jorge and we worked together to take it to its first commercial release, which happened in November 2006.” As Malcolm explains, in SynthMaker's case, VST export was always part of the plan: "We always knew that the software had to be able to produce output that would work independently of the main application.”

Both SynthEdit and SynthMaker follow the same basic virtual modular paradigm. Processing modules are joined together on screen with virtual patch cables in order to build up a patch, which can then be exported as a plug‑in. The two applications each come with an array of modules — filters, oscillators, envelopes, controls — all the components you'd expect in a modular synth and then some! You can also customise and add to the default modules, although the two packages each take a slightly different approach to this. SynthMaker has a simplified coding engine built in, so if you have the required knowledge you can delve into the code of the modules, customise them, or write your own modules from scratch within the program itself. SynthEdit has no such built‑in capability, but it allows the use of modules that have been written externally using the SynthEdit SDK. As a result, there are hundreds of third‑party modules to be found on‑line, some commercial and some free.

What About Macs?

Unfortunately for users of platforms other than the PC, the majority of the action in modular plug‑in development has taken place on the Windows side. There are some packages on the Mac with similar capabilities, but they have some limitations. SonicBirth for OS X is very similar in scope to both SynthEdit and SynthMaker, and creates both AU‑format and OS X VST plug‑ins. It's free and open‑source, although it was at one time a commercial application. Perhaps its biggest drawback is that the plug‑ins created aren't truly stand‑alone: SonicBirth plug‑ins need the program itself to be installed in order for to run in your host, effectively negating a lot of the benefit of the 'Save As...' feature. If you plan to commercialise your work, it does present a rather large point of difference compared to those originated in other development environments.

Cycling 74's MaxMSP until recently allowed for the creation of VST, AU and RTAS‑format plug‑ins on both the Windows and OS X platforms, but this has been discontinued in MaxMSP 5, so unfortunately it no longer remains a viable plug‑in development environment.

The Down Side Of 'Save As...'

This brings us to a common criticism of these environments when it comes to creating products to be sold. Plug‑in authors who use them are dependent on the developers of the software in terms of the code framework — the exported plug‑ins are really just a bundled‑up 'runtime' and preset in a VST wrapper — so if there's ever a problem that requires technical support, there are some very real limitations to what the plug‑in author can address on their own. A lot of SynthEdit developers ran into this problem in the last few years, when it came to light that multiple instances of SE plug‑ins on multi‑core machines could cause crashes and stability problems. Jeff McClintock has largely addressed this problem now in the openly available 1.1 beta, but up until then, developers could only suggest workarounds, not fix the underlying problem — an embarrassing situation for a developer to find themselves explaining to a customer.

The 'Save As...' environments have also had to battle a bit of a stigma with regard to the quality of their output. Developing in a visual environment definitely make it a lot easier to get your feet wet in plug‑in creation, but whenever a barrier to entry is broken, the likelihood is that there will be some sub‑standard work released. SynthEdit and SynthMaker both facilitated a flood of similar‑looking and ‑sounding synths and effects processors, many of which were little more than example projects and modules exported as VSTs. Jeff McClintock agrees that SynthEdit has played a part in increasing the number of amateur plug‑ins on the market. But, as he points out, "There's more cool ones too. A guy making his first basic plug‑in learns more about synthesis, he has a blast doing it. That's an end in itself.”

Breaking The Code

If you want to take a step closer to 'real' coding, but you're not ready to fire up the compiler just yet, Cockos Software's Reaper offers an interesting alternative in the form of its bundled 'JS' scripting language, which works on both Windows and Mac machines.A simple delay plug‑in being edited in OS X using Cockos' JS language.A simple delay plug‑in being edited in OS X using Cockos' JS language. Basically, JS takes care of all the basic audio and user‑interface stuff for you, freeing you to concentrate on writing your audio and MIDI processing in what they describe as a "C‑like language”, without having to do the grunt‑work of getting it to interface with your host and its plug‑in architecture. "Platform knowledge is pure hassle,” explains John Schwartz of the Reaper development team, who is also the author of the Schwa series of plug‑ins. "The knowledge you need for Windows VSTs is different from the knowledge you need for Audio Units. And even if you have a solid base of platform knowledge, it's still a pain to have to set up all the scaffolding your plug‑in needs. Reaper's JS language lets you avoid the hassle category completely.”

In contrast to the 'Save As...' environments, which concentrate primarily on your knowledge of modular building blocks and allow you to incorporate code if you need it, the combination of JS and Reaper requires at least a base level of programming knowledge if it is to produce results. So as a means to get your feet wet, it's not likely to provide the same instant gratification as its modular counterparts. On the other hand, the steeper learning curve does get you a step closer to 'real' coding, explains Schwartz.

"The JS code you write is effectively the interesting part of a VST, and what you end up with is effectively a VST plug‑in. For these reasons, JS is a true gateway language: once you've written a JS plug‑in, you're just a platform‑setup‑hassle away from writing a stand‑alone VST, and many JS authors go on to write stand‑alone plug‑ins.”

As you might expect, JS coding is still a great deal more complicated than authoring using the modular systems. If you're anything like me, your first sojourn into the inner workings of even a very simple JS plug‑in will result in a lot of frowning and head‑scratching. But there are dozens of example plug‑ins that you can pull apart, edit, and generally explore, and you can do all this while audio is playing through them, so you've got real-time feedback as to how your modifications (or sabotage!) are affecting the outcome. There's also a helpful on‑line community you can lean on for advice. You're not restricted to using your finished plug‑ins in Reaper, either: Cockos' free ReaPlugs package includes a VST‑to‑JS wrapper, so you can use these concoctions in other hosts. You may have to do some digging, though, as this plug‑in is confined to the pre‑release version of the package at the time of writing, and it's PC‑only for the moment.

So there you go. There's a bucket‑load of options for realising your own custom plug‑in dreams, from the relative ease of the modular environments all the way up to actual DSP coding. Best of all, every piece of software mentioned here is available either for free or on a trial basis, so you can jump in and see which tool suits you best before you invest any money.  

Why Write Your Own? A Personal Angle

Left: My voice‑mangling plug‑in being edited in SynthEdit.Left: My voice‑mangling plug‑in being edited in SynthEdit.Below: The compiled plug‑in at work on the SADiE H64.Below: The compiled plug‑in at work on the SADiE H64.

With such a staggering array of software processors and instruments already out there, why would you need to create your own? In my case, it was not about creating anything earth‑shatteringly new, so much as being able to easily group together a number of existing processes in a consistent way across a number of hosts. I was doing post‑production audio on an animated series that involved a character who lived in a mobile phone, and I needed to reproduce a variety of 'phone voice effects' consistently across a large number of episodes. I had been using combinations of compression, EQ, speaker convolution, distortion, sample and bit‑rate reduction and noise generation to achieve various different effects, and it became quite cumbersome to reproduce entire chains of different effects in differing combinations using the DAW's own plug‑in management. So, using SynthEdit and some third‑party modules, I built up a plug‑in that incorporated all of those processes in a user interface that gave me access to all the parameters I needed to tweak. What's more, I can use it in the future on any platform supporting the VST standard.

The 'Not Quite Save As VST' Environments

If the idea of modular audio creation interests you, but you don't need to bundle up your creations as stand‑alone plug‑ins, it's worth widening your view to look at some of the more traditional modular environments — and there are plenty to choose from!

On the free side of the fence, PureData is an open‑source graphical programming environment that shares a common heritage with MaxMSP. It won't let you create stand‑alones, but it's freely available for Mac, PC and Linux, so you can still share with others, albeit with a bit more rigmarole. Supercollider is another open‑source, cross‑platform option for audio‑related visual programming, along with Bonneville's CPS, all of which offer similar modular programming and routing options to the software discussed in the main article.

There's a host of commercial options as well, including Audiomulch, Bidule and Reaktor. The list goes on and on, covering price points and complexity across the spectrum. All share elements of the same paradigm — modules are connected together to form more complex instruments or effects — but offer various trade‑offs in terms of their approach to the task, functionality, interface foibles and so on. This list has only really scratched the surface. There are dozens of options, so if you're willing to hunt around you'll probably find something that fits your workflow and your budget.