Hi,

Just came across this one:

https://www.programmingformusicians.com/simplembcomp/

Could be useful.

Cheers!

 

A windows only python based vst scanner is the closest i came to vst sdk. Its impossible probably to port VST3 SDK completely in certain languages, just check FUnknown.cpp once

 

C/C++
Matlab
MFCC
AD/DA DSP
Assembly

 

i am not able to explain with the right words, because i am not a C++ programmer, but i can try.

the question is, what you mean with "VST standard".

the only thing beside a few things which we could call "container format", "VST" or "AAX" is mostly a set of "commands" which are to be followed.

and these "commands", i.e. the shape and functionality of the "end product" does not require to be written in a certain language, you could do that like you want.

for example, when a plug-in is started a by a host, the host might ask it "who are you? how many audio channels do you want? can you work in mono mode? do you have a GUI? how many paramaters do xou have? which ones would you like to hide from me? do you do anything besides the standard, like talking to USB drivers? would you please tell me when you have finished initilising? what´s your latency?"

the same goes for operation.

now if a plug-in only undertands spanish or if a host writes "tchenalz" instead of "channels", they wont be able to communicate, and the host will refuse to load it.

for example you can open most sonicworks plug-ins in cubase by hacking their identity to "VST plug-in". but most will chrash when you move a slider or when they receive audio in. because they do that different from the VST "conventions".)

it is just mostly based around C++, because there is a halfway supported and documented SDK available.

other than that i will ignore your question why it is C++, because there are people who can explain it better.

instead of that i can answer the second part, which is easy. ;)

because C++ is difficult for someone who does not know C++.

if are already used to delphi, max, or 56k machine language, and you have collected hundreds of custom tricks how to implement DSP code in your language, you will be happy to be able to continue programming mostly like you know it, and then later only build the actual plug-in using codewarrior/xcode or whatever is required to make it work.

nah, the tool does not matter, only the result does.

and btw, things like flowstone or juce are not completely inpdependent enviroments.

today you can run supercollider and csound code within max/msp, which itself is based on juce, created compiled code from that, and then build a live plug-in with it.
20 years ago you could also run your max patches in protools, because the made the whole max runtime (==program) compatible with VST, RTAS, and MAS.

or look into flowstone, how things are made there; if you know how, you can more or less skip the factory content for the core DSP and the GUI and write both in its assembly-like language.

and then *drumroll* there is an "export plug-in" feature in such programs - and guess what they do.

without opening and studying them inside-out one by one?[/quote]

most material in the audio DSP area is C++, followed by MaxMSP, and probably assebly, but the latter is usually not shared (and a pretty platform-specific thing.)

however i am sure that you can use openGL or the FFTW library in delphi, too. simply because it also exists for this platform and not only for C++.

it normally says what it is.

though when you look from outside at it, and it is C++ or java, you will not understand what it is and how to link it, that is normal.

they dont. some might pretend to, but they dont.

or they are simply too dumb to explain things in a ways a nood will understand.

i can try to give half an answer:

there are books (read about the basics),
there is practice (start working, not brood),
there are communities (ask questions and get help)
and libraries (lookup what others shared, use them as is, learn from it or modify them).

www.how-to-invent-a-new-reverb-and-get-rich.org/secrets-shared-only-with-you-today/?

tutorial 1: how to run on a computer, tutorial 2: what is the difference between whole numbers and fractions?

tutorial 3: will it hurt to type "VST development" into google? is it legal?

people are quite different. some learn from books, others just play around with things until they find their way.

so making a generic offer how to get into it is almost impossible.

 

Last edited: Dec 9, 2021

haha, schroeder is so horrible, you should replace it asap with that "newverb" patch, one of my favorite patches to teach newbies about reverb models.

 

Interesting, Thanks for the insight..

Actually by doing those questions I tried to follow a bit the Socratic method,
so that we can get different points of view/opinions, and clarify the whole matter to beginners like me,
who know about audio but don't know much about coding..

In retrospective I think part of the problem is the lack of good documentation by part of Steinberg and their minimal SDK..
Yes it exists, and yes it has some basic examples.. but the way it's presented, makes it quite unsubstantial/yet very steep for those who are not already C++ Programmers to begin with..


So yeah, basic stuff like that is very necessary, like say knowing/determining the Structure of a VST plugin.
What are the Obligatory and most Elemental Parts that make a VST plug?

And it's a matter of etiquette too,
you wouldn't go to a dinner party, without knowing how to behave minimally, or what to expect in that specific party..
do I have to wear a mask?

Like literally, is it a matter of Formatting, as in text..
(does it must include such and such arguments for opening, closing, have all these Structural parts, formatted this/that way etc..
or maybe a matter of having a minimal amount of parts/files dedicated to deal with each aspect of it..?)

Ofc the DSP code is the DSP code,
and that's the most crucial and Interesting thing of what makes a plugin.

But in order to make that DSP code work/run, apparently an entire flipping framework of stuff needs to be set-up,
and sort of included in your plug build/code too..

And that's what's very confusing/difficult for beginners..

In that sense Steinberg could have made a more graspable solution,
like a self standing vessel/framework or empty skeleton of a plug,
where one could simply go and declare what's the objects, and whats the function of those objects,
and just code the functions and structure of the plug and DSP code, but directly,
without having to go much through all the framework programming conundrum..

(arguably this could be more limiting for really experienced/able devs/programmers,
who could feel constrained/limited by such a structure.. but yeah, it could be made in such a way that both approaches were possible,
start from scratch with the SDK, or start from the pre-made skeleton of a plug, etc..)

Luckily that's what apparently things like JUCE are trying to do,
serve as a working framework, like a pre-made skeleton one can fill to "easily" be able to write/run your code.


"tutorial 3: will it hurt to type "VST development" into google? is it legal?"
Well to say the truth there's not (or wasn't at that moment) really all that much material that serves as a Complete course on VST coding.
Something that covers all aspects and steps, one by one, and in different situations/projects..

And that's what ppl needs really.. you could say I'm lazy, and that I need to learn and study this and that.. and it's in part true.
But I cannot spend 5-10 years learning to code C++ in the most global sense,
just to go back and be able to code a simple EQ or Compressor, which is what I wanted to do in the first place.. you know what I mean?

The only full tutorial that I found for coding a VST plug from scratch is already linked in my initial post,
but the thing is Outdated, and so Visual Studio will eventually say nanay at some point, leaving you stranded in the middle of the course.. lol

But well no problem, that was the Past..

Now, I have actually been following this courses by Matkat:
https://www.youtube.com/c/MatkatMusic/videos

Which are like step-by-step tutorials based on JUCE..
I'm half-way through the Simple-EQ, and have the MBComp prepared/working, for when I finish the EQ..

Great stuff to say the least..

But well, you know what I mean..
I should be following Steinberg's very own courses,
instead of depending on this great man's Generosity and audacity..

And also depend on the framework that a third party (JUCE) had to develop, (and capitalizes on)
just to make the thing more ready/graspable for regular humans..

Steinberg has made a good thing with the VST standards,
but hasn't provided a way to deal with it with ease by non experienced programmers..


"just play around with things until they find their way."
Yeah I'm more this type of guy,
I can read some and document myself, have the stuff ready for when it's needed..
But I'm certainly more of a tinkerer..

"making a generic offer how to get into it is almost impossible"
Interesting!

Why do you think so, can you tell us more?
Or what would be necessary in your view?


-In a completely different topic.. what you guys think about LV2?
I mean.. in technical terms,
is there any area where LV2 plugs are lacking in comparison with VST3 plugs?

Or is the LV2 standard every bit as much capable/performant and featured as VST3?

What's the fundamental differences, or what's the approach when coding a LV2 plug?

I guess the actual DSP code is pretty much made/structured in a similar way,
but what about the surrounding/containing Structure/fundamentals.. is it very rigid bureaucratic/obfuscated?
Or is it nice and easy?

If they are just equally as good/capable,
I guess it will be a good thing if devs jump into it and make it the new standard..

 

Last edited: Dec 9, 2021

Well, the topic is too complex so I'm just gonna add some things.
The VST standard is in C++. Because to write real-time DSP you need two things of a language:
- Speed
- Manually memory handling by the programmer
C++ is the best candidate because there's no other popular language with manually allocated memory. Also, as a consequence this only leaves "true compiled" (compiled directly to assembler) languages as alternative.

Java, Swift(Apple) and .NET can be very fast but they use "automatic" memory handling. They use "garbage collection" which is basically freeing automatically memory when it's not needed anymore. This make the language way easier and productive but they slow down in random moments because allocating and freeing memory is slow. Slow translates to huge latency spikes in a plugin. Using garbage collection almost always implies non "true compiled" language (.Net programs are run by the .NET interpreter (framework), Java, Swift have their own.

The other language that was used before VST3 was modern Pascal versions (Object Pascal, Delphi, Free Pascal). It checks the requirements. The dev of CodeFn42 MIDI plugins, great ones, uses Delphi. Total Commander is also developed in some variant of Object Pascal. Also, some DSP oriented languages that can run in C++ plugin "host". Like Csound and some others.

Now, as someone explained the API of VST plugins is complicated and you have to comply no matter what. They are hard and difficult rules to follow. hence that good language analogy even if we stay talk about C++. The VST3 standard is big mess in this department, it's very hard. Especially in the GUI department.

The JUCE guys have made their almost monopoly because of that. That's why you'll see those DSP languages like Max, Csound etc running on top of a JUCE layer.

That being said, if you don't need a lot of processing power you can develop in almost every language as long you have a wrapper/bridge/bindings with the the VST3 API rules. There's a .NET VST library for instance.

I was going to write more but I forgot and I'm lazy.

 

Last edited: Dec 9, 2021

Oh yes, alternatives, guides, lack of proper documentation, tuts, and boiler-plate (ready to code) stuff. Hmmm... reserved post for other day?

 

VST3 has a lot more interfaces than LV2 does, but I also think LV2 is a better solution. Both VST3 and LV2 are extensible, but LV2 is in C and VST3 is in C++. C++ by nature is a messy language.

Actually, Rust is promising. It has no manual memory management issues while having no garbage collector. It compiles to native bytecode (no interpreter needed) and is as fast as C++ (or even faster). VST3 interfaces have been already ported on to Rust, but it was more like a WiP last time I checked.

I will try to explain difference between VST2 and 3 in very easy terms. For example, if in VST2 you have to request a plugin windows size change, you do that through a function call with something like WINDOW_RESIZE being one of its arguments. In VST3, its not as easy, first you have to query the plugin whether it supports resizing. If it supports then you have to initiate the process, then another call when resizing is being done and another when it finishes. This approach, improves the communication between host and plugin, at the cost of complexity.

VST2 was more of a one-size-fits-all solution, while VST3 is more like a professional contract between two entities. In VST2, GUI and DSP code had to be separated by dev. In 3, they are separated by default, you can choose to combine them back. GUI and DSP do run on different threads so its better to keep them separated in the code.

 

Yep, among the numerous candidates to replace C++ Rust is the most promising. And backed by Mozilla (Firefox).
Still too green though. But there's already very nice and powerful software made with it.

 

in restrospective, for our generation who already grew up with the idea of using delays to make a room simulation using delays to make a room simulation, like done in schröder or stautner reverb seems a bit boring.

yet the inner working of two combs arranged as allpass will remain a secret to the DSP newbie anyway, even when the structure is simple.

where the background of the diffusion mixer in dudas´ patch comes from? i always wanted to know that, too! but i have no idea.

but i am realla thankful for this thing, because for us non-theorists working code examples are more interesting than the original, reasoned, mathematical derivation behind it.

i´ve built various versions of "newverb", full-signal, multichannel/vbap, more reflections and so on, and the basic concept behind it just works in any situation. (though the diffusor in a 10-channel version can get tricky.)

the SDK just shows some examples of the basic functionality. and yes, as oon as you want to load an audio file into a buffer, you need to learn that from elsewhere.

but - and i can tell that without knowing this spefific language - in the end there is no place where you can learn how youw ant it to work. there are probably dozens of methods and techniques, some of which go far beyond "C++ basics" you can learn from a book.

yes. the gain slider.

rename the file to .png and it wont load.

change something in the SDK which makes the document tell the host it can only take 80 bit IEEE data in vectors of 2048 samples, and it will chrash. remove the pictures and you wont see the sllder anymore.

but it does not tell you how to make a 24 channel compressor which can play a video based on openAI.

i totally understand your point/question.

but, well, there are starting points: a simple example of how it can be done does already give you a part of the picture.

if you are able to build "gain", you will also be able to build a mono version of it.

or a version which allows +50 db.

any little example code or information already teaches you something and gives you abilities.

and most of it has nothing to do with "running inside a plug-in", exactly. the DSP itself is often even relatively easy to tranlate from one to the other programming langauge. it will totally different, but does the same. and the öatter is what it is all about.

that would be okay if it is your first programming enviroment and if you want to do more with it than make your own gain slider.

i hate this stuff, too. as well as i hate the deployment process especially but not only for macOS.

and i hate dependencies. so i prefer closed systems like max or kyma and will probably never start coding the "normal" way.

of course there are also things which are easier in C++ than in "easy" enviroments...

i agree.

while that is not the way a good C++ programmer works - but it would be just great to have a little utility where you can declare the ins and outs and a few other structural things and it generates the code for you. with the VST SDK this stuff is a mess.

actually that is - roughly - what you can do in faust or juce today. but it is not like that would not have a learning curve also.

the funny thing is that you have to code a simple eq, because there are dozens out there you could just copy.

what is difficult and what makes commercial products cost money is to provide continued support for AAX for 8 different MacOS with 8 different security nonsense requirements, transfer your GUI library from GL to metal, or to find out that there is yet another undocumented bug in the VST SDK.

if you dont care to be up to date and only code for your personal needs or to learn about DSP, pluggo and flowstone are still really good tools.

i´ve written close to 1000 plug-ins with max, and a basic pluggo patch providing 85% of all possible VST 2.1 functionality consist of less than 100 objects. i can teach you that in under 8 hours.

max4live is not yet that advanced and has some quirks, but it is a similar system, where you dont have to care too much about boring system stuff, so that you can concentrate on DSP and GUI, access/UX, and the one or other special functionality. (== the creative part of the work)

because i know a lot of people who do similar things but everyone has a different approach.

there is one point where you should actually start working instead of thinking about things - and there is another point where you should stop doing all by yourself and team up with others, who already know what you need.

for example i am (only) an innovator. i am not a production company or a salesman. if you can finalize my scratch, let´s be partners.

there are 8 billion potential partners, so i do not need to learn everything my own.

 

Last edited: Dec 10, 2021

Creating a fast, easy to understand and scaleable gui is hardest, afaik only Valhalla, FabFilter have managed it. Valhalla uses JUCE, and FF have their own UI framework and the VST3 docs improved quite a bit in 3.7.0

 

that video above shows very well what you are talking about, right?




me, after 20 years of programming, know by heart that i have to do something like 440*pow(2.\linear frequency input - 69) / 12. to get Hertz.

to be exact, i do not even have to remember it, i have written hundreds of classes for that kind of stuff which i can call by funny names.

but how the hell can you know that you have to type "switch (event type) (case Vst :: Event :: kNoteOnEvent" ??

okay, kNoteOnEvent is probably found in the SDK, but the rest is knowledge about the specific language - and it would be so much better if there would be just radiogroup buttons and menus for that, just as on the setup page at the beginning of the video where you choose instrument/effect and name/vendor id.

(choosing type "instrument" is just 2 bits difference at position 94 in the file - you could actually also do that by hand after compiling... oh wait, yes you can do that and make any instrument run in an effects slot... handle this tip with care...)

 

Would Python be helpful? Or just C++?

 

Python has Global Interpreter Lock(GIL) enabled by default. What it means is that only a single thread can run at a time (atleast that's how I think it is). All audio plugins have atleast 2 threads one for DSP and one for UI. While libraries like numpy etc. make mathematical operations quite fast, there are almost no good UI libraries for Python. There aren't any plumbing frameworks like JUCE either. There are certain DSP libraries though. The GIL can be released and certain libraries help you achieve that, but concurrency never was a focus for Python, like it is for JS or C#. Apart from that Python interpreter is not lightweight, by lightweight I mean something like Lua's interpreter which is like ~150KB. Your plugin bundle sizes will begin from ~100MB. Take a look at Waves License Server, it uses Python. Add the cost of DRM, optionally and your plugin will be a shitshow. PyPy is a better choice when it comes to performance than CPython as it uses JIT compilation.

 

Perhaps one or the other suggestion is preserved in it.
What do you want to program ?

Wie entwickelt man Softsynths
https://www.sequencer.de/synthesizer/threads/wie-entwickelt-man-softsynths.123326/