KVR Audio

Kylotan · Post by **Kylotan** » Fri Jun 02, 2017 1:42 pm

Hi all, I'd like to make a VSTi, but am not sure what the best toolkit to use for it is.

The "How To Create VST Plugins?" thread suggests JUCE, but that is not cheap at all, and I've briefly tried wdl-ol in the past and quickly found some worrying bugs that have existed for 5 years and don't look like being fixed soon.

I want something that is not as low level as the raw VST SDK. I'd prefer open source, but am willing to pay - just not the $700 that JUCE want in order to ditch their splash screen. (If I end up spending a lot of time on it, I might sell it, so I'd rather not have someone else's splash screen or a restrictive licence.)

I'm very familiar with C++ (as a game developer by day) so I don't mind that part; I just need something to speed development along and help with some or all of the boring stuff - FFTs, UI, MIDI input event handling, etc.

Target platform is Windows 64bit VST at a minimum; anything else would be a bonus.

Any suggestions?

BertKoor · Post by **BertKoor** » Fri Jun 02, 2017 2:20 pm

Kylotan wrote:The "How To Create VST Plugins?" thread suggests JUCE, but that is not cheap at all

The "Personal/Educational" edition of JUCE is free of charge. Are you sure you cannot live with it's limitations (50K revenue limit and a splash screen) for the very first plugin you're attempting to make?

If you're a professional developer: calculate how many hours of your work $700 is equal to. Do a simple POC with JUCE (educational) just to see how that goes. Then do a simular project with the bare bones VST SDK and limit that to half the hours from the first calculation. At the end: how far did you get? Is a $700 investment worth it?

Dozius · Post by **Dozius** » Fri Jun 02, 2017 2:44 pm

A lot of people use wdl with success, so I wouldn't worry too much. That specific bug you linked only affects standalone app builds anyways, not VST builds. You are also free to fix any bugs you do come across and contribute something back to the project.

I'd also suggest maybe checking out this (https://github.com/Youlean/IPlug-Youlean) fork, which has a bunch of GUI side improvements. Haven't tried it myself, but looks promising.

Kylotan · Post by **Kylotan** » Fri Jun 02, 2017 4:11 pm

BertKoor - the splash screen is not acceptable if I want to distribute the VST. As for the $700 calculation, it's not something I can justify up-front. This is a personal project, not a professional one, so if I was treating my time as money and choosing to save money, I'd just not do the project at all.

Dozius - in the link I posted, the underlying bug is actually in the RTAudio classes, where there's some unsafe multithreaded access to a certain resource. It might be true that plugin builds never trigger the problem, but it doesn't give me great confidence in it. Still, if that is the best option available, I'll use it - I'd just prefer something else.

PurpleSunray · Post by **PurpleSunray** » Fri Jun 02, 2017 4:18 pm

Well.. it's same like awlays.. you have 3 options:
1) Pull the cheapest shit code you can find into you project and don't care about quality (would be any of those not-/minimal-maintained open source libs).
2) Use the "instrusty standard" and pay for the high quality (JUCE)
3) Implement it on our own.

stratum · Post by **stratum** » Fri Jun 02, 2017 4:50 pm

At least, in this particular case the industry standard is not the same as (1).. pretty lucky industry, I'd say.

PurpleSunray · Post by **PurpleSunray** » Fri Jun 02, 2017 5:05 pm

Ahaha, yeah audio is lucky. On video you'r pretty much f*cked. libav is the standart there.. and it is 1) at the same time

stratum · Post by **stratum** » Fri Jun 02, 2017 5:10 pm

Ahaha, yeah audio is lucky. On video you'r pretty much f*cked. libav is the standart there.. and it is 1) at the same time

Libav is one of the good ones, actually, and still has documentation text like

"WARNING: avserver is unmaintained, largely broken and in need of a complete rewrite. It probably won’t work for you. Use at your own risk."

PurpleSunray · Post by **PurpleSunray** » Fri Jun 02, 2017 5:15 pm

ok.. libav (processing only) is pretty ok, you'r right, but don't look at the codecs .. acute danger of eye cancer.

(that's what my job is about ... my company spend last ~15years on implemeting from scratch what ffmpeg / libav / libavcodec already has implemented.... but with "automtive grade quality")

stratum · Post by **stratum** » Fri Jun 02, 2017 5:18 pm

Compared to some other highly relevant libraries that I won't name, it's very good, actually. It even has code comments:)

PurpleSunray · Post by **PurpleSunray** » Fri Jun 02, 2017 5:25 pm

Try to run a bunch of "system integrity" test streams on this ffmpeg libs.. and look how they explode :/
The problem with all that parsers & decoders is that they process data that comes from outside.
You don't want a buggy mp4 to cause a buffer overrun on some OMX hardware decoding driver or whatever ... and bring down your infotainment system.
Worst case the Car OEM wanted to save money and the instrument cluster is rendered by the same graphic chip. So your buggy mp4 file has just converted your speedmeter into a back screen

stratum · Post by **stratum** » Fri Jun 02, 2017 5:42 pm

All the codecs and networking code comes from outside, all the hardware you'll work with also comes from outside and they all interpret the "standards" according to their own wishes. Failure once in a blue moon is the norm and you have to handle it. That has been my video processing experience so far. I wouldn't want that kind of behavior in my car, though.

PurpleSunray · Post by **PurpleSunray** » Fri Jun 02, 2017 5:48 pm

Yep, 'traditional" codecs work like that.
Implement what the specification defines. And crash if stuff is outside of the specification.
Doesn't really matter on PC. Restart WMP, or get a bluescreen and restart PC worst case.
If don't want that, you need to add limits, sanity checks, exit conditions, .... on top.
Specification only tells you about how the bits should look like if they are according to spec.
That's easy to implement. It gets tricky if bits are outside of what the spec defines =)

stratum · Post by **stratum** » Fri Jun 02, 2017 5:54 pm

That kind of behavior seems to be pretty common. In the telecom field there is a language called erlang exactly for that. I have adopted it for converting that unreliable stuff to something reliable and used the same approach in the code I have written myself. that's mostly the old unix way of doing things. you have processes instead of threads, and if they die, it's ok, not the end of the world. It's not that the engine control module is rebooting and power brake is lost for that reason..

PurpleSunray · Post by **PurpleSunray** » Fri Jun 02, 2017 6:09 pm

I know about erlang as well

Securty-relevant stuff be won't be C code, don't worry.
Their aproach is really like: define the input of the system, define the output of the system and than generate code. Which can be validated ect pp..
But infotainment (not security-relevant) are Linux/QNX/Andriod systems, on SoC chips.
They run a whole bunch of drivers, a desktop shell, applications .. much like a normal PC system.
So you have kind of the same challenges, but expectations are way higher, because, as you say.. you don't want your Car infotainment to behave like our win95 pc

but I think we are hijacking that thread

VST development recommendations for experienced C++ coder?