How To Create VST Plugins? Information for those just getting started

[kmh]

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.

Hi Everyone! I lead product & partnerships at MuseHub, it’s a recently launched Steam/App Store style platform that allows audio apps and plugins developers to distribute and sell their products directly! I would love us to onboard some of your finished projects on the platform! You can get all the info you need here and apply to join https://developer.musehub.com/muse-partners-help (https://developer.musehub.com/muse-partners-help)

I would love to answer any questions you might have!

Cheers

[SideChainKid]

Thanks for these resources, I just got into coding and scripting (logic scripts) music stuff. Very useful!

Any specific resources for midi fx anyone?

[maxchristensenaudio]

Just getting started with this. Thanks for all the resources

[StrangeSatellite]

Just thought I would chime in here as someone who started this journey not too long ago. I'm loving it and it's basically taking up all of my free time now, and I thought I would share a few things I've learned early on which might save some of you the time of figuring this out on your own.

First, there really aren't shortcuts here. You are going to need to learn C++ if you're serious about this. Using a no-code or low-code framework like many people here seem to suggest is not a viable route if you're planning to eventually be able to release a commercial plugin. This is because you'll need to be able to debug and maintain it. If the underlying C++ is abstracted away from you or you don't fully understand it, you won't be able to do this. Eventually some group of your customers will have some problems running your plugin on a certain platform, for example, and you will need to be able to dig into the nuts an bolts of your plugin to fix it. These frameworks make you reliant on their creators to fix bugs, and that's if the bug is in their framework and not your code. You can't release professional software (or really even free software) from this position. Yes, there have been a few commercial releases on Hise, but they're few and far between, and almost all of them are basically just sample players. Here's the best resource I've found for learning C++: https://www.studyplan.dev/intro-to-programming

Second, learning DSP is a separate skill and is also necessary. It involves math that some may find to be pretty intense at first. Learning DSP is made easier if you use some kind of DSP prototyping language or software. One very popular visual platform is MaxMSP. Another, and my favorite, is Faust, which is a DSP-oriented programming language. It's not as visual as Max, but it really lets you focus on learning DSP and the associated math, and then you can compile your Faust code into C++ classes that can be wired into a JUCE project, for example. There's also PureData, which I don't use, but it's the free predecessor to Max.

Third, learn JUCE - it will make your life much easier.

Fourth, use Visual Studio Community 2026 if you're on Windows. JUCE now supports it. You can use the CMake toolchain (CLion, VSCode), but it's more complex for beginners to set up, and JUCE just works with VS2026.

Fifth, you are unlikely to be able to "vibe code" your way through this with LLMs. While an LLM can code a website, there is relatively little DSP knowledge in their training data and they have a very hard time following signal flow in a logical manner. They can be a useful tool if you already understand how to create a plugin on your own (to speed up writing simple structures within your code or to wire your DSP code up to JUCE, for example), but I would say you have a zero percent chance of creating a working plugin with an LLM if you don't have any of the required knowledge in the first place. They are objectively terrible at it.

Fifth, understand that this is a huge subject to learn, and it's going to take some time to feel that your feet are on solid ground.

If I were to start again from scratch, the very first thing I would recommend is learning Faust.

Homepage: https://faust.grame.fr/
Web IDE: https://faustide.grame.fr/
A great free intro course: https://www.kadenze.com/courses/real-ti ... faust/info

You won't build plugins right away, but it does allow you to learn DSP and hear the results very quickly, which should spark further curiosity and (at least for me) really helps build a sense of excitement for learning more.

[aciddose]

First, there really aren't shortcuts here. You are going to need to learn C++ if you're serious about this.

C++ is a solid language, as C mostly is still lacking namespaces (due to avoidance of name mangling) and template meta-programming. Templates ultimately are the biggest reason C++ is viable for large scale projects, because unlike in C where you'd have to use macros, templates allow you far more flexibility. Templates can reduce the overhead of similar code to near zero, dramatically improving code reuse with the only overhead being the naturally double size of the compiled machine code for two variants of a similar function.

Second, learning DSP is a separate skill and is also necessary. It involves math that some may find to be pretty intense at first.

Mostly this is about mathematics rather than programming. It has very little to do with programming or abstraction in general, but those who have the innate ability to intuit mathematical properties ("all curves are straight lines in a different space projection transform") or work well with similar abstractions will find both mathematics and programming come naturally. In terms of mathematics, understanding algebra and calculus is absolutely necessary. Although this does not require rote memorization you might learn in low level college courses but rather requires an intuition of high level abstract "like-for-like". For example: the ability to recognize that the Gaussian function is emergent rather than an innate property of reality; that addition, multiplication, exponentiation, tetration and their inverses exist as steps of order (0, 1, 2, 3) but that the actual line is continuous such that order 0.5 (or -0.5) properties are most common in nature (such as pink spectra, normal distributions, ...) and arbitrary orders exist; that the order of a mathematical operation is simply a space transformation wherein a straight line is formed in the order of that space (for example, exponential decays are simply a straight line at order 1, where the delta is still a constant multiplicative per time step.)

Forgive me for stating the obvious. Point being that these ought to be somewhat intuitive to you if you are a natural programmer because ultimately programming requires the same sort of "world view".

This is an old but still excellent book, mostly for the ending chapter on Benford's law which demonstrates the transforms I mentioned. I've seen this posted before: https://www.dspguide.com/ch1.htm

In essence something like x^2 or 1/x or log(x) are merely "bending" the space wherein "x" is still a straight line in that "curved space". In this sense there is no such thing as a "curve", but rather different spaces through which a straight line appears "curved" via the "lens" of linear space. Again, in that sense you're merely looking at a straight line "in the wrong space" rather than "looking at a curve".

Third, learn JUCE - it will make your life much easier.

There are many disadvantages to library and framework utilization. Most obvious is the debt to the code you are unable to customize such that mistakes in the library or framework directly lead to mistakes in your own implementations using that code via derivation. The advantage may appear to be that you do not need to implement your own code or work as hard, but the truth is in fact that you in balance need to work less hard in some areas and much harder in others. It is near a zero-sum, and the benefits are mostly available to those who are lucky enough that their use in practice aligns solely with "work less hard" rather than "work more hard".

Fourth, use Visual Studio Community 2026 if you're on Windows.

It is bad advice to use any single IDE or compiler and toolchain. You should ensure your code functions correctly across all toolchains and strictly avoid wrapping things in ifdefs to provide multiple variants of source code for each platform. The ideal design is where you abstract your interfaces enough that you simply compile a platform specific translation unit (source file) and the abstract interface then calls "create_x()" for a variant of that object compatible with the platform in question.

Fifth, you are unlikely to be able to "vibe code" your way through this with LLMs. While an LLM can code a website, there is relatively little DSP knowledge in their training data and they have a very hard time following signal flow in a logical manner.

This isn't true. I believe it suffices to say that you need good code to begin with. An LLM will trivially translate this code into alternative forms for you (such as an SSE or AVX variant.) Most of the work involves cleaning up the garbage output generated by most LLMs to ensure it has the same quality of the input code you provided. If you start with garbage code, you'll get garbage code. Garbage in, garbage out.

What is absolutely true is that an LLM can not assist you as a tool with thinking. They are incapable of thought and merely perform what is in essence shuffling of the same things. They are excellent at producing high labor, zero intelligence output ("code monkey code"), but an LLM can never help you to design or think or correct your mistakes. An LLM is completely unaware of what a mistake is and will willingly produce an "optimized" version of good source code which no longer functions correctly at all. Understanding "what is functional?" remains strictly a human capability. This is why I believe an LLM is not "AI", because intelligence is defined by the capability to reflect on inputs, outputs and expense to judge cost versus benefit and potentiality of future benefits. In that sense, the computer player in a game of Chess is "AI", but an LLM is not. This is because the "artificial" aspect is that "win the game" has been added to the system by its author as a goal. Therefore you are in essence playing against the author of the "AI" in such a game. An LLM however merely scrambles things to create what is most probable to appear as valid and lacks a goal or the ability to make judgements of cost versus benefit, potentiality or otherwise.

Okay, rant over. Sorry for the wall of text. I hope it contains one or two useful bits for everyone.

[mystran]

First, there really aren't shortcuts here. You are going to need to learn C++ if you're serious about this.

C++ is a solid language, as C mostly is still lacking namespaces (due to avoidance of name mangling) and template meta-programming. Templates ultimately are the biggest reason C++ is viable for large scale projects, because unlike in C where you'd have to use macros, templates allow you far more flexibility.

RAII is also a big deal in larger projects. Not only does it simplify memory management, it can also simplify control flow by allowing you to defer clean up (eg. closing files or whatever) to "whenever this function exits." Whenever I have a bug related to cleaning something up, it's almost invariably because for one reason or another I didn't use RAII.

While C++ doesn't enforce lifetimes the way Rust does, it does give you the tools to structure your code in a similar way (using RAII) and it's usually a good idea to do so.

You should ensure your code functions correctly across all toolchains and strictly avoid wrapping things in ifdefs to provide multiple variants of source code for each platform.

Practically speaking it's typically impossible to completely avoid #ifdefs (because Windows like to do even basic things differently from every other platform) ... but I agree in principle: put the platform/toolchain/whatever dependent code in separate modules (or headers) as much as possible and try to keep the bulk of it clean. Makes porting to the next platform a lot less painful experience.

[aciddose]

Practically speaking it's typically impossible to completely avoid #ifdefs (because Windows like to do even basic things differently from every other platform) ...

Absolutely, of course they are required. What is really nasty however is the style I wanted to point toward avoiding, where the same source file includes three or more platforms. It's best instead to absolutely minimize this as much as possible because it becomes nightmarish and bug prone to create code like that. (With what is ideally four source files, the abstract, platform1, platform2 and platform3 being all in myobject.cxx instead.)

I did think of that while posting but much like the several other similar places in my post, I felt leaving it abstract and open was better than clarifying too much. Sort of a koan form in that sense, it ought to make the reader think both or multiple things to understand the difference between them. To promote doubt, which leads to understanding.

edit: Just to clarify, this means when you read things I say I prefer they're not taken as either strictly "true" or strictly "false", "right/wrong" or so on. Rather you ought to read and ask "is that true?" and consider what is said. When it comes to "it becomes nightmarish and bug prone to create code like that", this is true - in a particular configuration and particular parameters in a particular way - however it is also false - again in the same way but different particularities. Understanding the difference between these, just like using "goto" (ALWAYS AVOID IT! ) will most likely help you to write better code.

[spectraoul]

I would add DPF (DISTHRO) in audio plugin frameworks
https://github.com/distrho/dpf

[Tiles]

Diving into the AI assisted VST development at the moment. What i can say is that using one of the visual solutions in conjunction with AI doesn't really work well. I tried Hise, Reaktor, Pure Data, and another one that i have forgotten now. And AI was absolutely in trouble with it. I even tried to feed Claude with the pure text format of Pure Data. So that we don't need to discuss which button is meant this time. And it still struggled big time.

Installing Juce at the moment. Let's see how this turns out. AI seems to have ways less trouble to write code than with the visual solutions.