Plugin format (software folks, opinions needed)

[chillhuman]

My question is pretty simple - if I were going to sit down and start working on a plugin to use in Ableton on Windows, what format/libraries should I use?

I will be doing all of this in C++, on Windows. Since the plugin framework is up in the air, I plan to keep the worker code encapsulated away from the framework code, but I would rather pick the plugin framework correctly from the beginning.

I have been playing around with the VST package from Steinberg. Fortunately I found a copy of the "old" libraries because the new VST framework is a total dog compared to the previous. More features, but very complicated to use, and even though there are compatibility wrappers, I prefer simplicity. For Win is there a better alternative?

Also, I looked into M4L, and I don't think I want to go that route. If I have to, then I can make it work, but I'm doing this just as much to learn Visual Studio and the new features in C++11 so I would rather have most of it be code centric.

Many thanks!

[Airyck]

I looked into this a little before because I wanted to get into it too. I really believe your best bet is to continue with the VST SDK. It's the most widely used format out there and every DAW today supports it. VST 2.4 is still a viable option and you could later convert to VST 3 if you felt the need.

Now I haven't done much programing outside of Reaktor/(a tiny bit of Max/and the example plugins that are in the VST 2.4 SDK so I can't help you with many more details but if you're looking to make something that is the most usable VST is definitely still the way to go right now.

Look into JUCE as well, I know a lot of people use that for programing plugins.
http://www.juce.com/

From the website:

The JUCE Library

JUCE (Jules' Utility Class Extensions) is an all-encompassing C++ class library for developing cross-platform software.

It contains pretty much everything you're likely to need to create most applications, and is particularly well-suited for building highly-customised GUIs, and for handling graphics and sound.

I'm proud to have received a lot of praise over the years for the quality of the codebase, so would encourage you to dig into the code and have a look for yourself - hopefully you'll like what you see!

[tummes]

I have played a little bit with wdl-ol and it is fairly easy even though I am not a C++ programmer (Barely even a programmer). You can export to VST, AU, AAX and iOS. Definitely worth a look: https://github.com/olilarkin/wdl-ol

[mmorgan]

Since you are doing Windows only I would suggest looking into VST.Net. It encapsulates some of the gory details to help get started, then, once you are more familiar with the native VST API you can get into that also.

[chillhuman]

Since you are doing Windows only I would suggest looking into VST.Net. It encapsulates some of the gory details to help get started, then, once you are more familiar with the native VST API you can get into that also.

That's pretty interesting. Would I incur a performance penalty by using .Net? It looks like I would be tied into using C#, but I think I can.....manage. I don't know that I would want to be tied to Win, which is what makes C++ so appealing to me if I ever decided to port.

[mcdreamer]

Since you are doing Windows only I would suggest looking into VST.Net. It encapsulates some of the gory details to help get started, then, once you are more familiar with the native VST API you can get into that also.

That's pretty interesting. Would I incur a performance penalty by using .Net? It looks like I would be tied into using C#, but I think I can.....manage. I don't know that I would want to be tied to Win, which is what makes C++ so appealing to me if I ever decided to port.

My personal opinion would be to steer clear of VST.Net. I can't imagine it offers anything other than a managed wrapper to the VST SDK so it's really just getting in the way and ties you to C#. Stick to C++ as that will be more flexible going forward. Not to mention more efficient than writing managed code.

[mmorgan]

Since you are doing Windows only I would suggest looking into VST.Net. It encapsulates some of the gory details to help get started, then, once you are more familiar with the native VST API you can get into that also.

That's pretty interesting. Would I incur a performance penalty by using .Net? It looks like I would be tied into using C#, but I think I can.....manage. I don't know that I would want to be tied to Win, which is what makes C++ so appealing to me if I ever decided to port.

You're original post specified Windows only which is why I referenced VST.Net. If you are doing OSX and Windows then VST.Net would be inappropriate. You can code C++ in a .NET development environment. I'm unsure of any performance penalty but my guess would be if there is one it would be small.

Also my thinking was that VST.Net would be helpful getting you into VST development faster (though maybe not) than going through raw API calls for Windows form and control creation. I started with VST.Net and it was a big help. I no longer use it but that is because I am doing multi-platform dev.

Hope you find what you need.

[Venetian]

I suggest you try JUCE

used by many audio developers and offers good potential for interface development too

the Martin Robinson book is available online i think

or at least this chapter is:
https://www.packtpub.com/sites/default/ ... ter-01.pdf