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

[Fender19]

I'd take the more pessimistic view and say it's no surprise when a host or plug-in crashes or doesn't work as expected.

Frustratingly, there is often no sure way to say whether the host or plug-ins worked correctly or failed to meet a non-existent specification. One can say that the system we've employed to ensure things work has been trial and error in a sort of biological/evolutionary sense.

So from that perspective it might start to become clear why "still struggling after ten years" has been a sort of inevitability from the beginning. Only... replace "ten" with "infinity".

I agree with you 100%. It is especially hard for someone like me who is a novice programmer in general. On the other hand, I asked a very experienced programmer for help one time and he looked at the VST code like it was from outer space. It's a field of it's own for sure.

What makes troubleshooting difficult is that I often can't tell if it's MY PLUGIN or the HOST that has the error. I recently wrote a plugin that worked perfectly in Steinberg's VST3 Test Host and numerous DAWs but then DID NOT work right in Cubase! Is it THEIR fault or MY fault? (In this case it turned out to be MY fault - a missing function that other DAWs don't use).

Build it and test it in as many DAWs as possible. Surely it will not work in ALL. But how good is "good enough"? 4 out of 5 DAWs, 9 out of 10 DAWs, etc.? The amount of hours put in to get that "one more DAW" to work can become huge.

Just make sure to have a good refund policy that encourages "try the demo before you buy it" I guess.

[aciddose]

The best we can do is to test many hosts. Ideally you should have written your own host as well as a "host logger" that reports communication (opcodes, etc) from a host and also saves them to a log file.

I have my own host and my host analysis tool, so I can implement various sorts of tests to figure out how a host or plug-in behaves. If my code crashes inside a host I can in the least identify what causes it to happen. In cases where there is a host bug you can't actually fix the problem and rarely at best you can find ways to avoid it or work around triggering it. Ideally hosts should fix such bugs when they exist and plug-ins should not work around them... but this is a consequence of the lack of any specification and that evolutionary process I mentioned.

If a plug-in needs to run in an arguably buggy host like Cubase and the authors refuse to fix the problems on their end, you are forced to implement work-arounds to allow your plug-in to take up the most possible market share. Fortunately it seems such hosts are going extinct, but unfortunately the actions of plug-in authors to "work around" and "work with" buggy hosts reduces the evolutionary pressure on those hosts to either fix themselves or die.

Eliminating some of the official sources for VST2 is just another way to abuse monopoly control of that part of the plug-in market. It's entirely intended to reduce competition and force competitors to operate on the monopoly's terms which are obviously going to tilt toward those which favor the monopoly. Note that while they no longer support you there are alternative sources (GPL, etc) for the interface that will allow you to legally build VST2 plug-ins entirely free from their control.

[Vokbuz]

I'd take the more pessimistic view and say it's no surprise when a host or plug-in crashes or doesn't work as expected.

+1. When something works from the very beginning I get even more suspicious

[mystran]

The beginner programmer usually believes someone else's code must be buggy. The veteran programmer usually believes their own code must be buggy. The expert programmer doesn't really care, since they know they are going to have to fix it themselves either way.

On a more serious note, there's not a whole lot point in arguing what behavior is correct or wrong, since what you really want to figure out instead is how to make two pieces of software inter-operate as well as possible within the limitations of what you can influence (which for the most part is usually your own code).

[11nikita11]

Hi everyone i want to make vocoder with 16 band-pass filters. How i must start with?

[aciddose]

http://lmgtfy.com/?q=vst+vocoder+how+to
http://lmgtfy.com/?q=modular+software+s ... zer+how+to

Basically you need programming experience to start. Since you seem to have very little to none, look up "what is a vocoder?" and "how does a vocoder work?"

I'll provide short answers here:

A vocoder is a set of filters designed to mimic the tonality of the human vocal tract with a matching (usually nearly duplicate) set of filters applied to a "modulator" vocal (or other) input signal. The amplitude of the signal passing through each one of the filters in the metering set is measured and the amplitude envelope is applied to the "carrier" filters. This allows the filtered carrier signal to take on an approximately equal spectrum to the "modulator" reference input.

So your set of steps are:

1. Learn to program
2. Create a basic plug-in (a gain plug-in with one parameter: volume)
3. Learn about filters
4. Implement some filters as a basic plug-in (type, cutoff, res, volume, etc)
5. Learn about envelope followers, peak meters and other metering techniques (RMS, ...)
6. Implement a pair of filters and an envelope follower as a basic plug-in
7. Set up N (16?) of these sets (mod filter -> follower -> carrier filter) as a basic plug-in

You can skip steps #1 and #2 if you use something like Reaper's JS (C-like) to create your "code".

[aciddose]

As for modularity: basically in any modular system there is a set of common "interfaces" for the different modules.

For example in an analog modular synthesizer you have:

• The physical - space for the PCBs usually in a "rack" with space for the user interface on the "panel"
• Implementation interface - a power supply, input and output signals for audio and parameters
• User interface - the inputs/outputs visible to the user including signals and parameters editable via knobs and sockets (patch cables) or similar

Each aspect of the system is defined ahead of time such as the exact power supply voltages, amount of current supplied and some guidance on how to best filter/regulate the supply into each module to avoid interference with other modules. Likewise rules and advice are provided for signal I/O including both audio and modulation/parameters and again for the UI such as knob and socket spacings, text sizes, parameter and signal ranges and I/O properties (impedence, ...) and a few other rules like physical mounting hardware.

This common set of rules allows you to plug-in a module to the system and have seamless interoperability with any other modules without them needing to know ahead of time anything at all about any other module. The system is the only thing the modules need to know about.

For example computer software is "modular" in that sense. It only needs to know about the system/OS it is running on and can function seamlessly with many other software modules.

I'm not sure what you were looking for but you'll understand this intuitively after programming for a long time: modularity is an essential element of any engineering discipline and definitely a part of programming.

[mystran]

You can skip steps #1 and #2 if you use something like Reaper's JS (javascript) to create your "code".

Reaper's "JS" refers to JesuSonic (though apparently they call the language EEL2) which really has nothing to do with JavaScript.

[Vokbuz]

Does any-body did modular synthesizers?

Depends on the meaning of "modular". Most synths I own and know can be considered modular, you can route modulation very flexibly in them. If you want to make a virtual rack, there is vcvrack for example.

[aciddose]

You can skip steps #1 and #2 if you use something like Reaper's JS (javascript) to create your "code".

Reaper's "JS" refers to JesuSonic (though apparently they call the language EEL2) which really has nothing to do with JavaScript.

Ah, right. I've only used it a tiny bit and decided it's actually a lot harder to use than C/C++. I remember it looking a lot like javascript (or any C-dialect with additional or modified features.) It has the same sort of features: a few additional weird syntaxes for definitions (gui, i/o, functions, constants) but basically C-like. So anyone with experience using something like javascript should be able to pick it up very quickly.

So I should have said "C-like" rather than "javascript".

[aciddose]

Does any-body did modular synthesizers?

Depends on the meaning of "modular". Most synths I own and know can be considered modular, you can route modulation very flexibly in them. If you want to make a virtual rack, there is vcvrack for example.

"Module" means you can add/remove functionality. So you could consider a synthesizer modular if you could add or remove oscillators as well as build your own. Most of the "modular synthesizer" plug-ins are in fact not modular because they have a limited list of pre-defined modules written directly into the code by the authors. That's like saying you have a "DAW that supports plug-ins" - "... but it only works with these five `plug-ins` that are part of the DAW." Well, if you can't "plug-in" the plug-ins they aren't plug-ins at all.

I described the meaning of "modular" in my post where I talked about the fact that by definition "modular" means an interface specification.

Otherwise you could consider a ROMpler to be "modular" since you can "modularly" "plug-in" the different presets from the factory bank. Or a DX7 could be considered "modular" because you can select from four (modulation, pedal, aftertouch, breath) different modulation inputs! That's nonsense, obviously.

A synthesizer like the MS-20 is considered "semi-modular" because you can't remove or exchange the built-in components. You can plug-in external components and "replace/bypass" the internal modules by inserting or sampling signals from different points in the internal signal path. So it is indeed "partially/semi-modular" but not fully.

[DanBailiff]

I just made this "awesome list" with my favourite DSP and audio programming resources (focussing on C++).

https://github.com/olilarkin/awesome-musicdsp

DUDE! This is awesome. Thank you so much for this. I have been googling for the past hour to find stuff on this topic and you just handed me all this great info.

[dkravan]

Semi related.. Is there a library or similar that given a location will scan for audio plugins and return name, version etc?

[BertKoor]

Semi related.. Is there a library or similar that given a location will scan for audio plugins and return name, version etc?

No, but this should be a fun beginners project.

Scanning a folder is what the OS does for you, and there are already dozens of ways to do that. No need to add another.
Once you have a specific .dll file, you load it and check it conforms to the VST API. If it does, it might be kind enough to tell you name / version ifc you call the right methods / entrt points of the AppProgramsInterface.

[hannesmenzel]

Hello there. When I started to get into VST programming not so long ago, this list was really helpful for the first steps.

Regarding the listed frameworks you may possibly update, that afaik Cockos IPlug was discontinued, so in that domain Oli Larkins IPlug2 would be the best start.