OMG, what a fail!

Didn't realize that. Just started to read the 3.5 docs this weekend...

What's so bad about that ? I would have thought it's more flexible this way, you can leave all the knob assignment duties to the host, map knobs to different controls dependending on context, etc. Admiteddly I haven't written any synths yet, though.

As i understand it you can tell the host what mapping to make

"To inform the host about this MIDI CCs to Plug-in parameters mapping, the Plug-in should implement the IMidiMapping interface.
If the mapping has changed, the Plug-in should call IComponentHandler::restartComponent (kMidiCCAssignmentChanged) to inform the host about this change. "


I don't think VST3 is a fail at all, but it is really complicated compared to VST2!

It's an abstraction that shields information that could be needed by a plugin... Say a midi mapper?

The 'service' they offer is fine and will probably benefit a lot of plugins. But that is no reason to make it impossible for the plugin to process this info...

So in my world you would get the midi CCs always and if you implement IMidiMapping (or how that interface is called) you would also get the service. There is hardly any overhead in providing this data.

I don't think VST3 is a fail in general, just some small details
Problem is that problems are usually solved with these details.

And I don't think its complicated at all (from what I can read in the docs). In my opinion it's a better design than VST 2.4. Easier to develop, maintain and extend.

When I read the VST3 specs I get the suspicion that they looked very closely at my VST.NET design

Wow thread jacked like crazy xD

Haha well anyway, ive been trying to get everything figured out on my own but ive been running into a lot of errors simply trying to compile the gain sample supplied in the Steinberg SDK 2.4

Before I go on, is installing microsoft SDK necessary? I could have sworn i had it installed, but i guess not. I'm having an ungodly amount of errors trying to properly install that itself... but onto the vst stuff-

I've been following this to simply try and get a clean compile going and test out the results:

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

to no avail. Im getting the following errors:

description file

Error LNK1120: 2 Unresolved externals - gain test.lib
LNK2001: unresolved external symbol VSTPluginMain
LNK2001: unresolved external symbol VSTPluginMain

(two of the same thing)

Completely clueless at this point. I've made sure the linker input builds were all correct (the ones listed under "release builds", minus the optional ones)

Really not sure what else to do. Any suggestions?

Perhaps you are using a .def file to import VSTPluginMain, while you should use it to export it.

i actually think i somehow managed to solve the problem for that, but im having other (more) compiling errors now lol

i havent tried to fix them myself yet however as i was busy with another project, but i will try and get em resolved today or tomorrow.

EDIT: figured it out- had the release libraries set up for the building. switched to debug libraries listed in above link and it builds fine (with some warnings, but fine regardless)

however, is this an issue if i try making a "release" plugin, or can i just use the debug libraries regardless? a bit confused as to the difference between them

Also- im trying to get the plugin to load in cubase/FL studio but i keep getting the "program cant start because MSVCR100D.dll is missing from your computer"


which im 90% positive its not o.O

Link errors "always" indicate a problem with the linker finding the implementation of a method (or field). In this case the compiler was satisfied 'cause somewhere in your code you declare the function (as external?). Now the linker has to tie all the implementations together and can't find this one.

Sure you don't have some #ifdef DEBUG or somthing around that? Or you're not compiling/linking all the same files in release?

Difference between release and debug is that the debug version is usually not optimized - this is to allow a 1:1 relationship between the executing code and your source file(s). Also it is customary to include extra -sanity- checks in a debug build (using conditional compilation statements #ifdef/#ifndef etc).

In a release build "all options" are on to create fast lean code (you can tweak this of course). Debugging a release build program (if you enable generating the symbols) is awkward because the relation with the source files is screwed by optimizations the compiler performed.

The missing DLL looks like its from a Visual C++ redistributable package. Sure you've got that all installed? Otherwise try installing the (VS2010?) VC redistributable on your machine.

Hope it helps.
Last edited by obiwanjacobi on Wed Nov 14, 2012 1:29 am; edited 1 time in total

MSVCR100D.dll is a debug library, since it has a "D" at the end. The debug libraries aren't "redistributable" so (at least theoretically) you won't ever have them, unless you have Visual Studio installed.

Release builds should always use release libraries! It's not a good idea to use debug librarires for release anyway, since the release versions are (significantly) faster and more memory efficient and all that stuff. If you get link errors with one but not the other, there's something else going on.

For plugins, I would generally suggest "Multi-Threaded" rather than "Multi-Threaded DLL" as the library type; the "DLL" version requires MSVC redistributable package to be installed, where as the "non-DLL" version statically links the crap into the binary. The "downside" is that your plugin will then have a "private copy" of the CRT.. but in real-world plugin situation I kinda like this more of a "additional benefit" than a problem (all the "problems" MS lists, are mostly "good things" when it comes to 3rd party inter-op).

Also, in some cases the linker has trouble when combining static libraries in "creative ways" into a DLL target. These can sometimes be solved by selecting the "use library dependency inputs" setting in the DLL project's "Linker -> General" properties (I think it then uses the ".obj" files instead of the ".lib" which will slow the link down a bit, but seems to work better).

This is one of the things that I hate about MSVC. Debugging optimized release builds with gcc+gdb is "slighly confusing" where as trying to debug release builds in MSVC you can usually pretty much forget the concept of "source level" debugging. The damn debugger just doesn't seem to understand release code at all, and you often find yourself with not much more than disassembly + registers.

cool thanks for the info! ill get back to work on it today after class and check it out.

as far as having a ifdef DEBUG statement, im not positive. i've only skimmed over the source code for now, im simply using the gain plugin source code for now that was located in the vstsdk2.4 folder. Figured try to get things to build correctly first, then figure out what they are doing in the code (though i did look through some algorithms for particular plugin components).

as far as the mswhateverD.dll file, perhaps i dont have the packages installed anymore. I recall as i was re-installing visual studio + microsoft SDK, i was having a LOT of errors trying to install them. the reason being because i had previously installed them for school, but after the game design class i took i had uninstalled things such as visual studio, and dont recall which ones i uninstalled and whether they were removed correctly or not.

I think what ill do is completely remove everything and start from scratch again, just to make sure it all installs correctly.


I had another question that i didnt want to start another post for. As mentioned i was looking at other algorithms for plugins and such and i was wondering, do all basic effects plugins follow the same code? IE for making say a clip distortion effect, is there only one "optimal" way to code the process for doing so (for the actual distortion part, not counting filters or whatever) or do people still come up with their own ways? I ask cuz throughout my schooling ive done nothing but re-building the wheel so to speak even though much more efficient ways of building one have already been discovered.

I don't think there's "one optimal" way for anything. For "naive" clipping it pretty much comes down to max(minValue,min(maxValue,value)) but then again such "naive" clipping aliases like hell, so personally I wouldn't ever want to clip audio in such a way, except maybe as a safe-guard in low-level driver interfacing code (for example to avoid integer wrap-around, which is even worse).

Typically you will need some utility stuff where you just want the "best" possible (meaning some trade-off between "fastest", "most precise" and "most flexible") approach, but I don't think you can build anything interesting out of such "utility only" code-base. You will probably need roughly one generic utility biquad (but with a plenty of ways to calculate parameters), and one or two FIR implementations, some sort of FFT, and so on. This is all stuff that you essentially implement once, and then you only touch that code, if you need more features or something. You want to learn it all though, so I wouldn't be surprised if schools made you "reinvent the wheels" here.

But you'll probably need just as much "custom code" for any non-trivial plugin: oscillators, musical filters, LFOs, envelope generators and followers, delay lines (both simple and modulated), waveshapers, etc. [edit: I'm not trying to imply that you wouldn't want to split such high-level components into various lower-level building blocks, but it gets very specific very quick]. Unless you're trying to do "yet another basic this-and-that" these will probably all require some custom approaches, specific to your requirements.

Remember that when it comes to music, the slightest differences can be meaningful (or completely meaningless; depends on both the differences themselves, and the context). I find that over the years, even my "standard utility code" has slowly drifted in a direction very specific to what I personally want to do.