Steinberg SDK. All the resources say HOW things should be. None of them say WHY THE HELL THAT IS?

[djomni]

I'll begin by saying that I have not done much in the way of vst programming. However, I am fairly familiar with signal processing and I'm damn good at the math of it all. I have written my own signal processing setups for years mostly in matlab and/or mathematica. I now wish to expand into making vst plugins. I've learned enough c++ to write programs to process audio, but the Steinberg SDK really pisses me off.

The first reason (and this is entirely my own problem) is that I'm used to defining the direction of signal flow between components. It seems to me, and maybe I'm wrong, that has got to be some means of defining this. I refuse to use a vpl like synthedit, as I believe unless it's a custom vpl, it's just cheating.

Second regarding the Steinberg SDK, I was hoping that someone could tell me WHAT IS ACTUALLY NECESSARY AND WHY? I cannot find any resource that adequately and comprehensively explains EXACTLY WHY the code in the SDK is as it is. What's the computer thinking while it's using this?


Any input would be greatly appreciated. Thanks to you all.

[rootbear]

The first reason (and this is entirely my own problem) is that I'm used to defining the direction of signal flow between components.

You can do, or "define" anything that is within c++'s capabilities. The VST SDK is mostly there to connect whatever you are doing into a VST host.

Second regarding the Steinberg SDK, I was hoping that someone could tell me WHAT IS ACTUALLY NECESSARY AND WHY?

Nothing but the VST SDK is necessary I think, I just include the whole thing in projects, well more like whatever is in the simple examples.
As for your why questions, it's not clear to me what you are asking.

[djomni]

As for your why questions, it's not clear to me what you are asking.

These files are defining the boundaries of a box containing a rodent. There are a certain number of holes in the box both so the rat can breath and so children may peek in and see the rodent. Why'd the guy who drilled the holes put them where they are, and why did he make the box with the dimensions he did?

Because it seems to me that he wasn't considering either the unobstructed view of the children, or the rat's ability to obtain adequate oxygen. He just wanted to get the damn holes drilled so he could go on break.


A metaphor is nothing if not weird. haha

[davidguda]

This just was probably the most awkward metaphor, anyhow.
What do you feel missing in the SDK?

[djomni]

I don't feel as if there's anything missing necessarily. However, I do believe this is a rather limiting framework. I believe if directed towards a resource to study in-depth the manner in which the host application communicates with the plugin, I may be able to devise a more elegant system. Or, a more elegant system for my own use. My last post may have communicated just a little too clearly how strangely my mind works.

So, if anyone could provide me with the following:

An in-depth and comprehensive analysis of the communication between a plugin and a host. Preferably from as many different perspectives as possible, both qualitative and quantitative.

A flow-chart of basic internal plugin operation. Just the framework. I don't need anything to do with dsp.



I would be very much obliged.

[djomni]

Nevermind. Scratch all that. I got this all figured now. Peace.

[mkdr]

Nevermind. Scratch all that. I got this all figured now. Peace.

Cool. It seems the SDK is really well documented. Just over 30 minutes to figure all that out

[stratum]

An in-depth and comprehensive analysis of the communication between a plugin and a host. Preferably from as many different perspectives as possible, both qualitative and quantitative.

Is this about vst2.x or 3.x? 2.x interfaces are simpler, and a little hacking will get you something working and relatively trouble free. 3.x interfaces are complex, require some familarity with COM programming and... inadequately documented considering their complexity. A little hacking still gets you something working, but more debugging and testing effort is required, and in the end it leaves you in doubt because even when %90 of the host interfaces are not implemented things still seem fine. For example I've written a VST3 host, implemented only 2 of the host interfaces, and didn't call GUI event callbacks to the plugins, and the plugins that I was able to find (there isn't many) and tested still work fine.

[Alatar]

Hello djomni,
My advice: Use JUCE instead:http://www.rawmaterialsoftware.com/index.php.

It is a higher level library and does interfacing with the VST SDK for you.
Additionally it is cross platform compatible and provides many useful audio functions and features.

[DougCox]

I realize you've got it all figured out, but for those who don't, I'm writing a simple tutorial on writing a simple VST host using Steinberg's minihost.cpp as a start. It's at jdmcox.com/VST.txt.

[LemonLime]

Even though you said you got it all figured out, I'll add a quck tip that I use in debugging. Create some sort of a system (either through macros or a class) where you output to a debug file some info about what is taking place in each (or most) of the functions in the plug-in as they are called by the host.

For example, in your plug-in constructor, write out that the plug-in is constructing with initialized parameter settings. Write to the file whenever resume() or suspend() (assuming VST 2.x) are called, again with parameters. Write whenever parameters are changed, and in any custom functions/classes that you use. Write in the plug-ins destructor. Etc. etc.

Then when you run the plug-in in different hosts you can get an idea of how it's operating and how each hosts handles the communication.