Is JUCE an improved version of VSTGUI? [JUCE VS VSTGUI]

[Jackson Steel]

Why Steve Duda said this "Personally I'm content with just VSTSDK and VSTGUI however, and it is fairly lightweight and I can do things extremely fast"? lightweight?

https://www.reddit.com/r/edmproduction/ ... roduction/
https://xferrecords.com/forums/general/ ... wn-plugins

[EvilDragon]

JUCE is far more than just a GUI toolkit. At any rate it's UI development part is much easier to use, more logically laid out, with less strange bugs (especially concerning Linux and resizeable interfaces) than VSTGUI.

[superplek]

You can write an entire synthesizer using the JUCE framework without having to bother with the nitty-gritty (unless you want to of course) of either the building blocks of an audio processor, synthesizer or what have you or a well-working multi-platform GUI. For my taste it is sometimes a little over-engineered left and right but we use it for our plug-ins (though we have our own synthesis engine, but that has a couple of reasons other than JUCE).

We've also had little to no problem deploying for OSX and Windows flawlessly compiling and working out of the box, which is a big plus; you can focus on for ex. your instrument instead of tons of boilerplate code.

[Jackson Steel]

with less strange bugs (especially concerning Linux and resizeable interfaces) than VSTGUI.

How?

[EvilDragon]

Because it's coded better and code reviewed more properly.

[pottering]

Why Steve Duda said this "Personally I'm content with just VSTSDK and VSTGUI however, and it is fairly lightweight and I can do things extremely fast"? lightweight?

https://www.reddit.com/r/edmproduction/ ... roduction/
https://xferrecords.com/forums/general/ ... wn-plugins

That reddit post is from eight years ago, and this is the full quote:

I jumped into VSTSDK and VSTGUI, just compiling examples and hacking from there. I knew absolutely nothing about C++ and almost nothing about DSP. Was the long road. I'd recommend to look at JUCE, if I were starting over I would probably go the JUCE route (although it isn't free for commercial use, it is still a bargain in that respect). Personally I'm content with just VSTSDK and VSTGUI however, and it is fairly lightweight and I can do things extremely fast, and probably most important for me it is familiar and comfortable.

Full quote from Xfer's forum is similar:

I don't use JUCE (well, not exactly, I use it for a custom test host for debugging, I may implement more bits of it). I use VSTGUI and a few other libraries such as Boost and SQLite. JUCE is a fine way to go however. I wouldn't recommend taking my advice, I often do things the hard way, but either way, it's still years of dedication and work, and ultimately "what you use" doesn't matter much (just like the DAW or OS debates). JUCE is probably the right choice, as it's free if you keep things open source, should you make a commercial plug-in the price tag really isn't bad considering what you get.

As for other knowledge, it's just so many sources I wouldn't dare try to list them. There's no shortcuts as far as I'm concerned, eventually you want or need to understand things at the lowest levels, so in some ways it makes sense to start with nothing as well.

But with that said here's a good starting point, I would recommend learning about everything mentioned in the first post before moving forward
http://www.kvraudio.com/forum/viewtopic ... 3&t=329696
(I spent months in Reaktor literally, months in Max/MSP, CSound, etc and wouldn't have ever had a clue what do do in C if I didn't have that fluency first).

Hope this helps,
-Steve

So, he actually uses JUCE (a bit), and he actually recommends it for new devs over VSTGUI.

He clearly separates "what I use" from "what is recommended".

Also, he links to a sticky post of this very sub-forum, you should read those stickies.

Serum was released in 2014, but Steve Duda releases plugins since at least 2003, JUCE started in 2004 and its popularity is much more recent (AFAIK), so seems he simply started before JUCE was a thing and is used to the older frameworks (he is pretty successful using those, no reason for him to rush any change).

So when he implies "when I started things were different", that "when" is around 2000, maybe even 90s, not around 2014 (Serum), much less 2020.

[The Nerdy Music Guy]

Porting a plugin to an entirely new framework is a nightmare and a loooooooooooot of work, so it makes sense to stick to VSTGUI if you already use it, but it's definitely advisable to use JUCE if you are starting a new project.

[Markus Krause]

I am still using VSTGUI since I know it very well. The VST3 SDK is not beginner friendly at all, has a bad documentation and no proper examples for VST 2.4 compatibitly and single-components.
The JUCE framework is more easy to program, but also very bloated. I also do not want to depend from another company. JUCE recently has been bought by Roli. We devs don't know for sure what this means for the future of JUCE

[mystran]

I am still using VSTGUI since I know it very well.

There is a lot of wisdom in this. I use a custom framework written on top of raw Win32 and Cocoa (and wrappers for plugins APIs when writing plugins), since I know it well and I know the raw APIs well enough to add whatever I need. Would I recommend this approach to a beginner? Absolutely not.

[Markus Krause]

I am using a modded version of VSTGUI 3.6 (Cocoa & GDI+) for most of the plugins. This is safe for the future but you can't easily zoom stuff.
The new product with VST 3.7 is VSTGUI 4.9 (Direct2d & OpenGL).

I'd prefer a combination of Direct2D (PC) and Metal (Mac) these days to be safe for the future. So far none of the frameworks supports metal. This could result in a drama in the plugin-world once Apple decides to drop OpenGL support

[EvilDragon]

The JUCE framework is more easy to program, but also very bloated.

No. Steinberg's APIs are the very definition of bloat (just look at VST3). JUCE is actually efficient. It also does more things than VST3SDK+VSTGUI, but that is not bloat - that's what makes it a great framework. It has a SVG parser, for example, VSTGUI doesn't.

I also do not want to depend from another company. JUCE recently has been bought by Roli. We devs don't know for sure what this means for the future of JUCE

You depend on Steinberg for VSTGUI anyways, so unsure why you wouldn't want to depend on another company, when you already ARE. Also ROLI acquired JUCE not recently, but in 2014, and JUCE only got way better for it since ROLI invested a lot into JUCE. Can't say that Steiny did the same for VSTGUI (because they didn't, and it's filled with bugs that don't get fixed. JUCE bugs actually get fixed).

It's clear what is the better choice.

EDIT: https://forum.juce.com/t/apple-metal-ac ... on/36261/5

So JUCE will support Metal and Vulkan as they're working on it. Safe for the future. And I bet they wrap up support for that way faster than Steiny.

[Xenakios]

Steinberg's APIs are the very definition of bloat (just look at VST3). JUCE is actually efficient.

Juce implements VST3 by inheritance from the Steinberg SDK stuff and therefore depends on quite a lot of code in that. So, when you build a VST3 plugin in Juce, it will contain code from both Juce and the Steinberg SDK. (Juce of course doesn't depend on the VSTGUI parts.)

[Xenakios]

edit : double

[EvilDragon]

I mean, sure... you gotta use VST3SDK to actually build VST3 plugins. But it's not JUCE's fault VST3SDK is a hot mess.

[arne]

Can't say that Steiny did the same for VSTGUI (because they didn't, and it's filled with bugs that don't get fixed.)

You mentioned this more than once now, can you point me to bug reports you are talking about?

Thanks.