Best ways to start building VST plugins with the most control?

[johnratius]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

I've taken a look at visual programming software to create VSTs:
-Reaktor
-Max
-SynthEdit
-FL Flowstone
-Bidule
-Usine
All of them have Pros and Cons. All of them have their own area of expertise, but I feel somewhat limited in all of them, (from my research) and I want some more flexibility.
The ones that seem to have the most potential (Max and Reaktor), from my research, require a purchase to either use the full capability of the software or something on those lines. I do not want to have to pay extra money for something I can work harder at, and get the same or similar result I am hoping to achieve. I also don't want to be able to only run my VST inside another VST (looking at you Reaktor).

So I took a look at software/languages that are built for programming audio:
-CSound
-Cabbage
-PureData
-SuperCollider
These seemed great from what I could tell, and have much more potential, but aren't quite what I am looking for. Maybe this is where I should begin to make my own VST plugins, but I feel like I need to know how the whole language works beforehand in order to get the most out of it.

I then looked more into these libraries for C++ (I chose C++ of other languages, because I know it pretty well already):
-JUCE
-WDL_OL (iPlug)
-iPlug2

I have more experience with these, as in I have attempted to follow a few tutorials. I have some feedback from what I have found:
JUCE:
-You must pay in order to make revenue
-You must use the GPL in order to remove the splashscreen
JUCE seemed to have the most documentation, but I feel that I am still a somewhat beginner in C++ since I found the docs and the tutorials a tad confusing.

WDL_OL:
-I heard it was the simplest, but while looking at some of the examples, I found it pretty confusing
-Seems a little outdated
I started the main tutorial http://www.martin-finke.de/blog/article ... roduction/ (http://www.martin-finke.de/blog/articles/audio-plugins-001-introduction/), but didn't get too far because it seemed way too out of date at this point.

iPlug2:
-Very little documentation and no tutorials yet
This one seemed most promising, but with only the few examples it provides, I felt like I couldn't get too far.

So, what do I know so far? I took an audio engineering course in college, and several C/C++ courses. I feel like I can take on making a VST, since I have had experience with Reaktor in the past, but am unsure where exactly to start. I know that I most likely can't take on anything huge right now, but I am wanting to start out small, and make a few small ones, such as a limiter, equalizer, etc...

So, my question...
Where should I really start making my own VSTs, with lots of flexibility, and decent documentation or tutorials or examples? I feel like I have been wasting my time trying to find the "best" framework, language or software to start with. I am guessing that many of the professional developers (xferrecords, u-He, Waves, iZotope, etc..) all use some form of C++. So I am aiming to start developing plugins in C++, but I guess I am unsure of what framework to start out with. I enjoy using the Cinder framework for OpenGL (Not really an audio framework), and I was hoping to find something like that in regards to a VST/audio framework.

What are your suggestions that I should begin?

[aciddose]

Ultimately if you want flexibility the most extreme version of that is "roll your own". I've done that over the past 20+ years and it's certainly well worth it if the end result isn't your primary focus, but merely a way to express yourself in your programming hobby and make valuable functional programs.

If you aren't interested in spending months to years writing your own frameworks and libraries you'll ultimately need to settle on one you can gain rights to modify and distribute. This generally means paying a license fee, or agreeing to abide by some sort of limitations that restrict your freedom to do as you please.

Alternatively we have FOSS which turns that on its head somewhat: you're free to do whatever you want, so long as you minimally do what we tell you and allow everyone else to do all of the same. So the freedom you ultimately exchange here is to keep secrets + to limit the rights of others.

Those are your three options and you must come to some form of compromise comprised of either one or multiple elements of these options mixed together.

[BertKoor]

So you have crawled, are starting to walk, but thinking about the entry fees for running a marathon.

It's an adventure. Just take one step at a time, plan just two steps ahead and it will be alright.

[mystran]

So you have crawled, are starting to walk, but thinking about the entry fees for running a marathon.

That's a pretty good way to put what I was going to say as well: don't worry about licensing costs for frameworks you can try for free, until after you've tried them for free first.

The thing about programming is that the only way to really get better is to write more code and the thing about getting better is that what seemed confusing at first will seem much easier in the future. So even if you pick something like JUCE now, you can decide later whether or not you think it's worth the license costs. In the meantime, you can focus on learning plugin development and I can basically guarantee that by the time you're comfortable writing plugins with JUCE, learning another framework is going to be a lot easier.

So really... when you're starting just pick whatever lets you get going the fastest. The best way to learn (and to get better at) programming is to open the damn editor and start writing code. It doesn't even matter too much what type of code, just open the editor and start typing.

[johnratius]

Thank you for your responses. I have a follow up question I don't think I quite understand.

What exactly is a VST? Like, is it a program that is in the form of a .dll file that is readable by a host DAW? Can any program be turned into a VST plugin that a DAW can read? (I am not focusing on Pro Tools plugins at this time) I would really enjoy making plugin GUIs and small VST plugins in a framework like Cinder or oF, but I have no clue how I would "convert" a app, or code in general, to a specific type of .dll file that is readable by a DAW. Does my question make sense?

Edit: I also started looking at VSTGUI and it seems pretty good.

[Xenakios]

What exactly is a VST? Like, is it a program that is in the form of a .dll file that is readable by a host DAW? Can any program be turned into a VST plugin that a DAW can read?

Plugins like VST plugins are essentially code libraries that are loaded dynamically at runtime and implement a particular API the host is expecting them to have.

It can very tricky to repurpose code originally written for a standalone application into a plugin. For the GUI parts it's probably not worth the effort and it's better to just start from scratch with an actual plugin development framework like Juce or IPlug. For the audio DSP parts, some amount of it can probably be repurposed for plugin use, if it's low level enough and doesn't depend much on the original development framework.

You can forget using frameworks like Cinder, Qt and so on, they have not been originally designed for audio plugin development.

[aciddose]

Thank you for your responses. I have a follow up question I don't think I quite understand.

What exactly is a VST? Like, is it a program that is in the form of a .dll file that is readable by a host DAW? Can any program be turned into a VST plugin that a DAW can read? (I am not focusing on Pro Tools plugins at this time) I would really enjoy making plugin GUIs and small VST plugins in a framework like Cinder or oF, but I have no clue how I would "convert" a app, or code in general, to a specific type of .dll file that is readable by a DAW. Does my question make sense?

Edit: I also started looking at VSTGUI and it seems pretty good.

A plug-in is a program using an interface specification. Unfortunately there is no official VST specification, and VST2 is obsoleted and no longer provided by the rights holders. There are fortunately open-source (GPL) and BSD-like licensed versions of the interface provided by others.

So yes, it's a dynamic library that is loaded by the host application and various functions are called. Generally an entrypoint function is called (both OS specified and interface specified functions sometimes exist: for example dllmain()) initially, then constructors are called to allocate an instance of the interface. Some interfaces don't utilize constructors and instead supply single global interfaces which are further used to allocate instances of sub-type objects (COM, DirectX, etc.)

The best thing you can do is learn how the interface itself works. In VST this is extremely simple and specified by a handful of small C structures and some function pointers with only a single constructor/instantiation function.

So VST is just a generic plug-in interface as you'd expect in any software and much like you'd be forced to write yourself (and may very well have) if you'd ever used modular plug-ins in your code.

This is one aspect where I can very strongly recommend that you actually study and understand how the interface works from the code itself: https://github.com/x42/lv2vst/blob/mast ... /vestige.h

You should be able to see after some time that the interface is specified by the vst::effect_t (aeffect) structure and vst::hostcallback_t (audioMasterCallback) function type declarations. The constructor/instantiator is a simple library function you export which accepts a pointer to the host callback and returns an allocated and partially initialized instance of an effect struct.

Many other structures and index values (integer enumerations, defined as preprocessor macros in vestige.h) are used to define opcodes and data used in a dispatch function in the effect struct. This dispatch function is used instead of individual functions to simplify the interface definition... but as a consequence it means all your implementation must be handled in-/directly from that one function.

Most of the VST opcodes are not usually needed, so the core dispatch() implementation should be trivially less than 200 lines.

In order to understand how a plug-in instance is configured and the GUI is allocated and displayed requires that you study and understand the dispatch() opcodes involved, and sadly there is no official documentation or valid specification for VST. You'll instead find documentation scattered in often 50/50 true/false and misleading mixtures. So you're best to ask questions here on the DSP and Plug-in Development forum to learn from the many highly experienced authors we have contributing here.

multi-edit: link to wiki article on dynamic dispatch, cleaned up formatting, fixed typo

[aciddose]

Note that the "updated" "VST3" interface is similar, but it is a reimplementation or "reinvention of the wheel". You'll need to figure out which interface you want to use: likely VST2 for compatibility and widespread support unless you need some of the few unique features of VST3 to write an esoteric plug-in.

Do not try to bend the interface. Only try to realize the truth: There is no "VST". Then you will realize it is not the interface that bends, it is only yourself. https://youtu.be/uAXtO5dMqEI

The joke is that when we say "VST" we're usually talking about VST2, and when people mean VST3 they'll almost always explicitly say "VST3" rather than "VST".

Some aspects of VST2 are rather awful from a number of different perspectives... but much like the win32 interface it has a certain beauty to it of the wabi-sabi with https://en.wikipedia.org/wiki/Shibui variety. It isn't pretty, but it works - most of the time.

Originating in the Muromachi period (1336–1573) as shibushi, the term originally referred to a sour or astringent taste, such as that of an unripe persimmon.[1] Shibui maintains that literal meaning still, and remains the antonym of amai (甘い), meaning 'sweet'.

(Shibby: the abstract "but that's contradictory" combination of the two meanings.)

Due to its simplicity you can re-write the code using modern c++ features and make it look a lot better. Unfortunately you can not fix issues such as a lack of string-lengths passed via the interface (instead they assume a pre-defined VERY SHORT string length which is usually ignored.)

[ilyaorlov]

Maybe you should take a look at Plug-n-Script by Blue Cat Audio.

[syntonica]

If you dig into the VST 2 framework, you'll find several convenience methods that aren't necessary to the main operations. Once you understand why they're there, you'll understand more about how VSTs work.

I looked at all the different Juces and iPlugs, etc., and you can learn a lot from looking at the code. However, I decided to roll my own GUI and interface mainly because it's my code and not someone else's code. Meaning, there may be bugs or breaking updates and its easier to be in my own brain and find them in my code. I hate debugging other people's code. I really do. Ask me how much I hate debugging other people's code!

I found that I was able to write only about 500 lines of code specifically for Mac and PC, each, with the bulk of my GUI code in a common method.

The downside of all this is that I'm still VST 2 only. I have to dig into the other frameworks to learn how they work and how to integrate them into my code or vice versa.

Annoying, I know, but each option has its own pros and cons, as has been said before.

[joshb]

VST2, VST3, AU & AAX are all very different specs, not to mention the UI differences of working on Macs or PCs. I chose to use JUCE and if I had to do it all over again, I would do it again in a minute.

Now, to be sure...writing plugins is a VERY steep learning curve, writing good DSP code is a VERY steep learning curve, dealing with UIs and installers can be torture. JUCE itself is a very steep learning curve. Every one of them can kick your ass on any given day. but by using JUCE, about 98% of my code is universal. Sorry to sound like a commercial, but it worked well for me, and the forum and knowledge base it pretty substantial.

[JustinJ]

I went through the same process some time ago and settled on Juce.

Why? On the whole it's really well written and thought out. It's got every UI drawing feature you'd want and it's easy to add your own components. It supports hardware and OpenGL acceleration, is cross platform and the same code compiles for VST, VST3, AU and standalone. It's well documented and comes with loads of demos with many more by users on github. Active forum, and on and on.

You get this kind of benefit: at some point Apple are deprecating and ditching OpenGL and going with Metal instead. Rest assured, the Juce devs will support this in advance and with hardly any effort I'll be able to switch without writing any of that code.

It's got a lot of commercial traction - I think UVI's Falcon was written using it.

Yes, there's a cost involved if you go commercial. But you don't have to pay anything until you do and frankly it's a drop in the ocean compared to how much money you'd save for your time. FWIW, the games industry went through a similar thing. Most companies used to roll their own game engines but at some point they asked what business they are in...the game engine business or the game making business? Hence Unity and Unreal. Same for audio.

[Lind0n]

You should look at HISE. VST/AU/AAX Mac and PC (and iOS) and VI's and effects all posisble.

[unevens]

in my opinion, understanding the api is not enough. there is a lot of know-how in the implementation.
you will have to learn things like managing the multi threaded realtime environment, before starting to roll off your own implementation on top of the vst/vst3 header.

a good way to learn that (or to work around it) is to use either JUCE or IPlug2 for a while, and see for example how they handle the communication between the dsp and the gui.
also, some daw have their own quirks, which are not easy to imagine just looking at api.
sdk are tested with many daws (one would hope all) and that will potentially save you some headaches.

personally, i learnt using JUCE, which in my opinion is very good but a bit too "crowded" with stuff.
you may have to learn more things than those you actually do need in order to use JUCE well.
but it is also true that learning the reasons why you do not need certain things will give you a better understanding of the whole situation.
also, JUCE has a nice forum with a big community, and there are a lot of open source plugins done with it.
so i'd suggest JUCE to start learning.

lately, as i prefer a more minimalistic approach, i'm moving to IPlug2, and i am liking it a lot.
but i already know what to expect from it and what to search for.

[ilyaorlov]

A new version of Plug'n Script by Blue Cat Audio is out, btw. It's a really powerful thing.
https://www.youtube.com/watch?v=UuKffpOFgWY

Learn more: https://pns.letimix.com/