Make VST2 plugs with C code only

[0degree]

It's also worth mentioning Steinberg has released official VST3 C compatible Api: https://github.com/steinbergmedia/vst3_c_api

Thanks! very helpful to know!!!

Anyone seen any example that uses it?

It's pretty new so my guess is there aren't many examples yet. It could be very useful for alternative languages such as Rust or Zig.
I hope Steinberg won't abandon this because it's quite cool

[xos]

It's also worth mentioning Steinberg has released official VST3 C compatible Api: https://github.com/steinbergmedia/vst3_c_api

Thanks! very helpful to know!!!

Anyone seen any example that uses it?

It's pretty new so my guess is there aren't many examples yet. It could be very useful for alternative languages such as Rust or Zig.
I hope Steinberg won't abandon this because it's quite cool

It may be that there isn't any example code at all on the internet for this. But at least this header exist. What would be needed is something like the following but for VST3...

https://github.com/pongasoft/vst24-hell ... plugin.cpp
...I used that as a starting example to write my first VST2 plugs in C code.
And I used a similar example to make my first Clap plug in C code before that, and it can be found here...
https://github.com/free-audio/clap/blob ... template.c

But even if I had example code, it was a lot of work to interpret a lot of missing stuff to make a useful plug that took many days, as there isn't much to go on, that can be found on the internet.

But a C example of a VST3 plug with almost no functionality at all would be better than nothing.

[0degree]

It's also worth mentioning Steinberg has released official VST3 C compatible Api: https://github.com/steinbergmedia/vst3_c_api

Thanks! very helpful to know!!!

Anyone seen any example that uses it?

It's pretty new so my guess is there aren't many examples yet. It could be very useful for alternative languages such as Rust or Zig.
I hope Steinberg won't abandon this because it's quite cool

It may be that there isn't any example code at all on the internet for this. But at least this header exist. What would be needed is something like the following but for VST3...

https://github.com/pongasoft/vst24-hell ... plugin.cpp
...I used that as a starting example to write my first VST2 plugs in C code.
And I used a similar example to make my first Clap plug in C code before that, and it can be found here...
https://github.com/free-audio/clap/blob ... template.c

But even if I had example code, it was a lot of work to interpret a lot of missing stuff to make a useful plug that took many days, as there isn't much to go on, that can be found on the internet.

But a C example of a VST3 plug with almost no functionality at all would be better than nothing.

As a matter of fact I'm working on Zig language bindings based on this C Api. It's very tedious because VST3 format is super bloated but it is what it is
You can always take a look at VST SDK C++ code and try to reverse engineer it to use C instead. Start with the exported plugin factory and follow the thread - you will need component, processor, editor, etc

[xos]

Xos, small trick for rewrite all licenses:
rename functions, structures, constants...
Like as: *AEffectDispatcherProc - *AudioManager, *AEffectSetParameterProc - ParamSettings...

I finally took the step to get rid of #include "aeffectx.h" in a VST2 plug, so I don't use Steinbergs headers any more. And did it without using the vestige or FTS header that is crippled with horrible GPL licences.

It was quite easy. I just got rid of the row #include "aeffectx.h" and compiled a minimal plug, and fixed everything that the compiler complained about.

And it was a good idea to do so, as it gave a good understanding exactly how little the original headers actually is needed. That proved to not be needed at all. And from here it feels like freedom. And it gives confidence. I would recommend it for any one that has made a VST2 plug in pure C code. Make a minimal plug in C and then then get rid of the include of the VST headers and make your plug compile by compiling and editing until it works.

To make it final, rename the enumerations and stuff. And tweak some declarations, and use FTS and vestige for some inspiration.

The only things needed is a function named VSTPluginMain. And a the number 1450406992. That is 0x56737450 in hexadecimal. Any idea of how to get rid of them also? Maybe another function name and identifier, and make it into a new plugin format. And then supply a program that opens the .dll file as a binary file and edits the file header so it can be used by music programs without the support for this new format.

[xos]

As a matter of fact I'm working on Zig language bindings based on this C Api. It's very tedious because VST3 format is super bloated but it is what it is
You can always take a look at VST SDK C++ code and try to reverse engineer it to use C instead. Start with the exported plugin factory and follow the thread - you will need component, processor, editor, etc

Interesting. Without knowing anything about VST3, does the exported plugin factory have any similarities to the one in the Clap format?

[DNnX]

The only things needed is a function named VSTPluginMain. And a the number 1450406992. That is 0x56737450 in hexadecimal. Any idea of how to get rid of them also? Maybe another function name and identifier, and make it into a new plugin format. And then supply a program that opens the .dll file as a binary file and edits the file header so it can be used by music programs without the support for this new format.

You can export that function as "main" instead of "VSTPluginMain".

The internal magic number 0x56737450 cannot be copyrighted.
There are no magical tricks like Nintendo GameBoy StartUp Logo

[xos]

The only things needed is a function named VSTPluginMain. And a the number 1450406992. That is 0x56737450 in hexadecimal. Any idea of how to get rid of them also? Maybe another function name and identifier, and make it into a new plugin format. And then supply a program that opens the .dll file as a binary file and edits the file header so it can be used by music programs without the support for this new format.

You can export that function as "main" instead of "VSTPluginMain".

The internal magic number 0x56737450 cannot be copyrighted.
There are no magical tricks like Nintendo GameBoy StartUp Logo

Thanks for the information! I tried it, and it worked

Yes, was it a court ruling that the magic number in gameboy carts was fair use, if I remember it right?
It's ironic that you mentioned gameboy carts. As I was the first to produce a open spec. for the cartridge protocol for gameboy advanced carts.

[0degree]

As a matter of fact I'm working on Zig language bindings based on this C Api. It's very tedious because VST3 format is super bloated but it is what it is
You can always take a look at VST SDK C++ code and try to reverse engineer it to use C instead. Start with the exported plugin factory and follow the thread - you will need component, processor, editor, etc

Interesting. Without knowing anything about VST3, does the exported plugin factory have any similarities to the one in the Clap format?

I've no idea, haven't look at the CLAP format, but from what I've heard it should be easier to implement

[xos]

Here is some alternative VST headers...
https://github.com/x42/lv2vst/blob/mast ... /vestige.h uses 'GPL2' or 'GPL3' or any newer future revision.
https://github.com/Xaymar/vst2sdk/blob/master/vst.h uses '2-clause BSD license'
https://github.com/pierreguillot/FTS/bl ... /fst/fst.h 'GPL3' or any newer future revision.
And of them not mentioned in this tread before...
https://github.com/Xaymar/vst2sdk/blob/master/vst.h uses '2-clause BSD license'

[BertKoor]

GPL? BSD?
Please consider the DBAD license
https://dbad-license.org/

[Super Piano Hater 64]

GPL? BSD?
Please consider the DBAD license
https://dbad-license.org/

I'm fond of the WTFPL myself.

Unfortunately, "friendly" licenses like these are a legal hazard, because their conditions are so vague that it's impossible to prove whether you're following them or not. Putting something under one of these licenses is a good way to make lawyers run away from it really fast. Thus, if you expect people to use your code, you should choose a license that's been in and out of the courtroom a few times (which GPL certainly has) or at least one that was actually drafted by a lawyer.

tl,dr: There are legal reasons to prefer BSD to DBAD.