I saw your share on the "sister site" and am eager to dive into it when I get the chance! I've wanted to mess around with programming plugins for a long time.

 

I've been trying to learn programing a VST myself, but I'm still a total Zero on the left,
I need to learn more about C++ and coding in general before I will be able to really dig into Pirkle's book..

Also I found it hard to find basic information like:
How's the minimal fully-working plugin Structured,
what Parts and Libraries must it include, etc..

Examples of how to code the separate Components that could make a plug..
You can find some stuff here and there, but it would be cool to have some sort of Compendium.

Prikle's book seems to be the best possible resource tho,
so I guess first one shall get his coding skills up to the book, and then pray..

Pray to the holy mother of steep learning curve.. :D

-Here's some useful links tho:
VST3 SDK - https://new.steinberg.net/developers/
VST3 SDK Documentation - https://steinbergmedia.github.io/vst3_doc/index.html
Steinberg Dev forum - https://forums.steinberg.net/c/developer/103/none

How to make VST plugins in Visual Studio:
http://teragonaudio.com/article/How-to-make-VST-plugins-in-Visual-Studio.html

Making Audio Plugins Tutorial:
http://www.martin-finke.de/blog/tags/making_audio_plugins.html
(the only good tutorial I could find,
however I got stuck at some point due to it being outdated/newer software working differently..)

iPlug 2 - C++ Audio Plug-in Framework - https://iplug2.github.io/

The Scientist and Engineer's Guide to DSP:
http://www.dspguide.com/pdfbook.htm

Cockos WDL library - https://www.cockos.com/wdl/
(don't ask me why but it seems it's used/well regarded by devs..)

Easy Plugin making Platforms:
https://rackafx.com/
http://www.synthedit.com/

Juce - https://juce.com/
JUCE 4.x for VST Plugin Dev - http://www.redwoodaudio.net/Tutorials/juce_for_vst_development__intro.html
Projucer Manual - https://juce.com/discover/stories/projucer-manual#6.1-juce-modules


If anyone can find better starting material, or another proper/better Tutorial,
please share it so we can all learn from it!

 

Last edited: May 29, 2021

These 2 books on the brother site this month are good meat to chew on:
Designing Software Synthesizer Plugins in C : With Audio DSP, 2nd Edition
Designing Audio Effect Plugins in C : For AAX, AU, and VST3 with DSP Theory (2nd Edition)

Also - consider the Flowstone platform (next generation of SynthEdit / SynthMaker).
Info VSTs made by the guys at Flowstoners.com

 

Last edited by a moderator: May 29, 2021

someone should create a GitHub repo and start a project where we can fork it.

 

Last edited: May 29, 2021

YES YES YES, I have been trying to get into this hard for the last few months and every forum was full of experts and couldn't understand anything. So this is a fantastic idea, CHEERS!!!

 

my teenage days (12-17) was filled with programming (Windows 95 days) but I part way with this world because my parents think it has no future (they are wrong, I know, but I forgive them already) and ask me to be some civil engineer or some shit, which I failed miserably because I was busy touring with my band. It (programming) is the first "thing" I fell in love with in my life, but it's already over for me and I moved on.

Just want to wish good luck for any of you that want to try this thing out. Don't forget to share your work here so we can test it out!

Start a Patreon or something and please don't add any lame protection whatsover, I'll put up post in request section in sister if I see one. lol. Good luck!

 

Last edited: May 29, 2021

DSP: https://www.musicdsp.org/en/latest/index.html

You may also want to consider JSFX for fast development
My "white paper"
Official docs

 

FlowStone | Overview - DSP Robotics
FlowStone uses a combination of graphical and text based programming.
http://www.dsprobotics.com/flowstone.html

(Example) : Adam Szabo - Viper VSTi (Made with Flowstone) GUI Size 200% 2048x1280 (4K Ready)

Custom GUI for VST Plugins by satYatunes. www.satyatunes.com/web/custom-gui.php

 

For those who want to wade in instead of going straight into the deep end may I recommend these wrappers: JSFX for Reaper and BlueCat's Plug'n Script

These let you concentrate on one aspect of plugin dev only (the processing code) which cuts down the barrier of entry, also the knowledge is transferable if you want to step up to native plugins with C++.

Also for prototyping algorithms you can't beat JupyterLab, which lets you write code and visualise the results (with numpy/matplotlib) directly with no compilation phases/refreshes/plugin loadings inbetween. With xeus-cling you can directly write C++ though it can be a hassle to install.

 

yea you needtolearn c plus plus i still have the vsti i made 13 years ago for collage it was a henry the hoover that made you guessed it hoovers, his eyes are the oscs and he nose was the detune knob

 

Last edited: May 29, 2021

Not true this, you can use Delphi, Rust or C# and I'm sure there are other bindings. The GUI can be anything that can link to C code.

 

I'm sorry, but this needs a little bit of clarification for half-brained, braying noobs like me..

Because it seems regular VST plugs are made with C++, but then..:

There's the JSFX plugins, which are different than VST, but use EEL2?

Flowstone uses Ruby?

And you say Delphi, Rust or C# can also be used..

How is that possible?
I mean, you could write/translate the same code in all those languages,
put it into Visual Studio, and compile it to make a VST just as good?

Or what's the difference between using one/another,
aren't different languages necessarily linked to a specific Compiler, and need to adhere to a specific Structural layout?

Is the VST standard compatible with all those languages?
Doesn't it need to adhere to a very specific language and structural layout, namely C++?
So why not learn, and approach it with C++ and that's it?

Or is it like..
It doesn't matter which Language you use, as long as it's Compiled in/from a Structurally compatible way/source,
the plug will run relatively as good regardless..?


-Are all Libraries and Frameworks (like iPlug2 or WDL) compatible with all languages and compilers?

And how can one know which libraries to use, which ones are an absolute requirement, or could be handy,
without opening and studying them inside-out one by one?

And how can one know how to communicate with those libraries,
do all libraries work the same, respond to a similar type of syntax/requests?

What's the libraries usually used for, and what are they Not used for?
What's the limits of what a library can do/give you?


And what about Phyton which seems to be favored by most coders these days?
Is it to slow for Audio DSP?

How can one know what one doesn't know? :D


I'm sorry if this is too Elemental, or seems like a step back, just trying a little bit of Socratic method here..
But it's stuff like this that Experienced programmers Know and take for granted,
but which noobs like me need to have clarified again and again at the beginning, until it clicks..

What I would really need is a a series of Tutorials that I can follow Blindly,
which take you from level 0, to being a plug programmer step by step..

But yeah I don't think that exists, beyond things like the little Tutorial I linked on my first reply,
or the awesome Prinkle Book, which covers the stuff up from a certain level of coding proficiency..

 

Last edited: May 29, 2021

I already have a name for a potentially AudioSex VST Plugin: AudioSexToy
...ye, was a bad one

What about a sub bass something called AudioSex Underwear VST?
...ye exactky, also stupid

If anyone needs a GUI, I'd like to do it.

 

Ok, I'll try to answer.

The VST SDK is C++ indeed, but anything that can link to it will work.

They're different, EEL2 compiles to machine code which is then executed by the host. In this case it's Reaper, or the Reaper JSFX VST plugins. So the execution of the code is handled by those.

I've not used Flowstone, but it seems to be a data manipulation framework. Useful perhaps for prototyping the audio manipulation code like Python/JupyterLab.

Ok, here perhaps a clarification is needed. A plugin is basically composed of three elements:

First there's the plugin code that actually processes the audio. It also maintains the GUI (but see below).

Then there's the runtime which is handled by the host, it sends the audio to the plugin and passes the received audio onwards. It also deals with sending and sending MIDI/event data to the plugin, and constructs a basic GUI if needed (like Airwindows plugins don't have their own interfaces etc.).

Third, there's the libraries linked to the plugin. Technically they're part of the plugin, but they could be external libraries (DLLs, so:s and dylibs)

VST is a standard, yes. It defines an API which the plugin needs to respond to, exactly. The VST host dynamically links the plugin and if it doesn't respond to. This is defined by Steinberg in C++.

However any code that can be compiled to respond to these API calls will work. this is called FFI (Foreign Function Interface), which is C code and it enables code written in several languages to talk to each other. For instance, it's possible to embed libraries written in C or C++ in Python via this mechanism. Examples are things like numpy.

C++ is hard and very beginner unfriendly, and you also have to learn the tooling (compilation, linking etc.) which means you most likely have to deal with CMake which is another very big swamp initially. Also if you use external libraries you should be able to handle those as well. The plugin frameworks are helpful here, but more often than not you have to go outside those and then deal with the dependencies.

They're compatible if there are bindings (code that bridges two programming languages together).

Plugin framework libraries basically abstract the mechanics of host APIs to a single interface. For instance iPlug2 presents a unified programming interface and can compile to Audio Units and VSTs alike.

But for instance that framework interface varies a bit, JUCE and iPlug2 are not compatible. But they do similar things so your actual DSP code will work with both with minimal changes. UIs are written completely differently.

Python is not really geared up to low latency multithreaded operation, it's not fast as such. All of the "fast" Python code relies on libraries written in C/C++ and so on. If you want to geek out look up GIL (Global Interpreter Lock)

Python, however, is fantastic for quickly prototyping DSP and UI code as you can edit the code and visualize it without any recompilation. Again, I'll mention JupyterLab.

Here's an example w/ Jupyter:

Spoiler

How does one learn? Reading docs and very importantly asking questions! We all have to start somewhere and nobody knows everything, se it's a learning experience for all of us.

 

A quick side note, since we're dealing with low-level data when creating plugins using C++ you have to be aware of C. Pointers, pointers to pointers, typedefs, null terminated strings, and all sorts of nasty shit.

So if you want to learn C++ start with "modern C++" which is to say C++11 standard onwards, but you have to be comfortable with some C things. And oh, C++ and C are not the same, don't ever fall to that trap.

The best free resource for learning C++ is LearnCPP and I'd recommend using exercises from HackerRank or Project Euler.

Feel free to ask if you need help setting up a development environment (IDE/editor, compiler, build tools and so on). LearnCPP has a section for these as well.

*edit*: https://en.cppreference.com/w/ is a must bookmark, stash it under your pillow, now.

 

Last edited by a moderator: May 29, 2021