JUCE adds a lot of garbage to the final release bundle, maybe uncompiled code as well. Try running all-in-one ripper from ExeInfoPE on a JUCE plugin DLL and just check out what gets dumped

 

Dang. I should learn C++ as well.

 

Getting complicated....

 

Nice thread, I'll revisit it later.

Creating VST (Virtual Studio Technology) plugins involves several aspects of coding, and it typically requires knowledge of C++ and familiarity with the VST SDK (Software Development Kit). If you have specific questions about VST plugin coding, feel free to ask, and I'll do my best to provide guidance on those aspects. Whether it's related to audio processing, user interfaces, or integrating the plugin into digital audio workstations (DAWs), I'm here to assist you.

 

I've been lurking, procrastinating and being a workaholic for too long. I'm about to have more free time than usual and I really want to sit down and make something cool.

Thank you for starting this.

 

many people who used something else before think that C++ would be more difficult or more "professional" than some of the other languages and tools.

in fact there is a lot of stuff which nowadays can be easier in native coding compared to capytalk, maxmsp, flowstone, you name it.


the main difference between these enviroments and C++ on the theoretical layer is that you can go deeper using C++ - if only you know how to.

simple examples: custom memory access, custom disc access, custom data types (such as multirate audio signals of different properties)

some o ther things are easier in graphical apps or specialized languages such as kyma, lisp, csound, max. mainly as they come with a bunch of examples and lively communites.


after almost 25 of maxmsp, when i look at AAX or VST SDK i am completely annoyed that you have to define and set all kind of abstract technial things for a project which are more or less the same for every plug-in.

i max, i couldnt care less if communication between compiled objects are atoms or something else and rather concentrate on the data itself and its mening to what i want to do.
in C++ i have to define such things in C++ terminology where in audio programming enviroments outputs are simply called "output".

otoh, making a proper GUI in max, supercollider or CSound is a science itself, where in modern interface builders you only had to press three buttons to do the same.

 

AI is now better at not only coding, but teaching you probably better than any human has time to teach. Grok3 can code. If you want to learn, have time, and are willing to commit to learning, it's not only doable but it's never been easier than it is now with AI. Got a question? can you read and write? Then use an industrial quality LLM as a learning aid.

 

interesting topic. things changed since. namely AI.
I also wanted to create a VST plugin myself.

Well lets say, it loads. functionalty isn't included as of now. but there is a window, a UI. WOHOO.

What I used:
1. claude code (inside WSL) with agents:
1.1 a project-coordinator/manager: has full oversights of the project and acts like a coordinator (coordinates work of other agents),
1.2 a coder: does the code stuff
1.3 a shell operator: who is aware of the OS environment, installed frameworks, etc. (has the EXPLICIT rights to install or change the (OS) environment - all other agents are not allowed to do so)
1.4 a research agent: web access for research (only used when the topics/problem is hugh)
2. frameworks: nih_plug (rust) and nih_plug_egui

this works quite well. so far

 

Last edited: Aug 24, 2025

ive been making so many plugins and apps with Cursor + Claude Code.

Installers, Project Managers, Audio Duplicate finders etc.. Loving this era of Idea to iteration

 

As a former C++ developer (game dev) I still only understand about 1% of anything DSP related so I'm super amused (concerned?) where are we going - since so many audio YouTubers are calling themselves
developers/coders now. And there seems to be a new "own" plugin coming about every week.

It will be interesting to see where this goes. How many vibed projects will die and slowly fade away...

(I just can't even imagine what it's like to jump into a LLM created project and trying to make any sense out of it. If you don't understand most of your code how are you going to do anything with the project? I guess every time you do something you just feed the entire code base to a LLM - sounds super efficient ;)

Then again, there's people like Airwindows's Chris Johnson, which gives me hope. Even following him do math/DSP related stuff (I have no idea what's going on most of the times) it was kinda funny to see him learn / figure out bitwise operations (pretty standard in older game dev)

 

Rust & NIH-PLUG, it has been my go to after developing in JUCE for years. I refuse to fight with vcpkg to get libraries working alongside JUCE anymore. Cargo is just too useful.

As for DSP maths, I would honestly suggest getting a feel for it as you go. DSP can be as complex as you make it, to what extend do you really need to understand digital filters (Difference Equations? Transfer Functions? Z-Transforms? Poles and Zeros?), you could spend a lifetime investigating DSP and its related topics, I say just develop plugins and acquire specifics as you go.

I'd certainly look into DSP maths in general as it will benefit you to know the behaviours of various processes. But it need not be a rigorous endeavour IMO.

Best of luck (to anyone interested), it can be a tough learning process, but one that is valuable if continued!

 

for me it is the other way round, i know a lot about all this audio releated stuff, but had a hard time to use c++ and the like.
so i focus on max and do everything there - fully aware that some things are more work there, and that the resulting process requires three times more CPU.

and that is somehow typical for the audio and video scene, that many coders and designer hate deployment processes and high evel development, but rather apply theoir knowledge about math and physics directly into playful combination of building blocks. this is more or less why enviroments like max, kyma, flowstone & co exist...

the perfect plug-in SDK for me was something where you do have to deal with memory management, disc access and driver communication because that part of the process can be created by clicking fancy colored icons, while on the other side the actual audio DSP should and may be laborious detail work, fully custom, with no third party classes at all.

 

I personally found it handy to simply create a simple harness in Python that takes a buffer of samples and plots it. Then I can precalculate things like phi etc., handle sample rate specific things (like calculate the frequency for a wavetable X samples in size) and simply plonk my DSP code into a loop and have a display that just updates, and plays back the sound when needed. Way easier to just deal with the DSP separately like that, and no annoying compile/test cycles.

No, it's not real time but Python maths code translates to C++ pretty easily and I can just add memory management as needed. Anyway, you don't deal with memory in the process loop (or anywhere in the hot audio path) so it's easy to separate into constructors/destructors (RAII rocks and you can model the code same way already in python).

Even easier would be to use jupyterlab, but I find the UX in that fairly miserable.

*edit:* Oh, and a shout out to Formula. Code your stuff in C inside your DAW.

 

yes, i am every very oldfashioned and tend to think that everything still works like 1999, where max/kyma/supercollider were the opposite paradigma of c++, where you had to build, compile, and load things to try them out, which is pretty counterintuitiv.

of course today (or well actually for about 20 years) there are easy options to do almost the same in visual studio or XCode... i remember seeing it the first time with audiounits, where people were coding, then it was compiling automatically in background and loaded/updated automatically in a plug-in host in a manner you hardly noticed it ecept a short audio dropout.

yet an app like max - or matlab for that matter - has all the analytic tools and visual controls onboard already, so you do not need to roll your own there.

 

Oh yeah, definitely, someone getting into audio programming should definitely start with stuff like Max, Puredata, SuperCollider, Faust, or one of them fancy browser-based livecoding environments like Strudel (which is SuperCollider underneath really).

It's just that beyond a certain point, especially stuff that calls for large data structures (other than sample buffers) then manipulating them in a graphical environment is a pain or just plain impossible. Then you end up using things like writing externals for Max or PD or wringing your algorithms with gen~ or what have you, which in my experience is not much fun either.

What I'm getting at I guess, is that at some point one has to cross the threshold from simply expressing the equations to handling them at discrete sample level.

 

i sometimes think (and experience that everyday when talking to noobs and students) that the more different tools and languages there are, the more difficult it becomes to start with one of them.

 

It took me a very long time to get to the point where i could write and understand C++, i did a lot of hobby projects until i had a solid grasp of it.

Then I started out with tutorials for building plugins in JUCE, i built something that made audio sound more alive.. it was an interesting.

I've since moved onto rust. Seems to be a lot faster and less crash-prone.

I started out by porting C++ code line by line to rust to learn the language, then i iterated on it and added match blocks etc. to improve readability.