VSTGUI vs JUCE

[Frot]

Hi all,

I just started my second major synth project. I did the first one with a tool called RackAFX which in turn generates VSTGUI code for you. The result was however mixed, the GUI feels sluggish at times. (This might very vell be due to my understanding of the inner workings of RackAFX / VSTGUI)

So this time I want to do it from scratch. The plugin will be rather big, with dozens of custom views where Osc/Filter/whatever modules can be chosen from dropdown menus, Tabs for different envelopes, XY pads etc.

My priorities are:
1. performance
2. performance
3. ease of use

From what I've read people seem to suggest JUCE for the task over VSTGUI, I didn't find too much on the topic of the two however. Is JUCE easily integratable with an already existing audio base? (I still do the audio algorithms in RackAFX, since it kicks ass at prototyping!) Any suggestion and comments appreciated!

[quikquak]

I've converted several existing VSTGUI plug-ins to Juce, and I'd say it was pretty straight forward - I kept all my DSP code intact. I don't know what VSTGUI is like now, but I like Juce's promise of being able to make VST2, VST3, AAX, AU and stand-alone at the same time. Plus there's the integrated OpenGL (hopefully soon to be Vulkan ) GPU acceleration, which is often a must have with today's 4K screens if you want anything animated.
Plus Juce's hierarchical window flow is really easy to use - but I guess I'm biased a bit as I use it a lot!
And you get a bunch of automatically loading audio format types, and you can call parameters by their string names and set their ranges outside of 0-1 through a normalising feature. I can go on and on...well for a bit anyhow...

[Karbon L. Forms]

Gah, that thing looks awful. And it won't run so I can't check it out. Maybe it's brilliant. Who know? lol

Looks like that thing exports cmake projects with generated vstsdk code. JUCE uses it's own plugin abstractions. You'll never see a CPlugin anywhere (maybe if you go digging). You could try shoe-horning a JUCE gui in as your editor but I'd run screaming from that idea myself (hooking up message loops and all kinds of crap? Not sure, I ran screaming years ago when Jules (Chief JUCEdude) told me not to attempt it and wait for his own implementation).

JUCE is designed to be used on its own and even has its own project generator. It has a GUI designer but I've never used it or heard of anyone who does.

I highly recommend it.

Ask here: https://forum.juce.com/

[Karbon L. Forms]

I've converted several existing VSTGUI plug-ins to Juce, and I'd say it was pretty straight forward - I kept all my DSP code intact. I don't know what VSTGUI is like now, but I like Juce's promise of being able to make VST2, VST3, AAX, AU and stand-alone at the same time. Plus there's the integrated OpenGL (hopefully soon to be Vulkan ) GPU acceleration, which is often a must have with today's 4K screens if you want anything animated.
Plus Juce's hierarchical window flow is really easy to use - but I guess I'm biased a bit as I use it a lot!
And you get a bunch of automatically loading audio format types, and you can call parameters by their string names and set their ranges outside of 0-1 through a normalising feature. I can go on and on...well for a bit anyhow...

Indeed, much goodness. I can barely remember what VSTGUI code looks like now. I do remember hating it though. lol

(What rocks me about juce at the minute is compiling to android using exact same code as windows and without ever having to even look at any Java/Kotlin)

[Big Tick]

Actually I'm one of the few left who like Vstgui. With my own layer on top for skinnable UI's, it requires a lot less code than Juce for similar results.

[Frot]

Cool thanks for your answers!

Gah, that thing looks awful. And it won't run so I can't check it out. Maybe it's brilliant. Who know? lol

I agree, it's not a thing of beaty as is, but it lets you start coding audio right away and handles all the knobby GUI mess - which is a godsend for beginners. Also the books by Will Pirkle use it (they're awesome!)

JUCE is designed to be used on its own and even has its own project generator. It has a GUI designer but I've never used it or heard of anyone who does.

Yeah I'd have no problem in just porting the DSP classes over to JUCE and rebuild the plugin there.

So JUCE it is?
(I just learned about the licence/splashscreen lol.)

[Rockatansky]

(I just learned about the licence/splashscreen lol.)

If you want to use it in GPL mode, switch the JUCER_ENABLE_GPL_MODE precompiler variable in Projucer’s AppConfig.h on, and compile the Projucer application yourself. The project for it is in the extras folder of your JUCE path. (You may have to move it to somewhere else outside of the JUCE folder if you run into compilation issues.) If I understood everything correctly, then GPL mode essentially means: no sign-in to Projucer required, no statistics sent to ROLI, no splash screen. Not 100% sure here, but I don't see any splash screens anywhere.

[Xenakios]

If I understood everything correctly, then GPL mode essentially means: no sign-in to Projucer required, no statistics sent to ROLI, no splash screen.

And you need to release all your source code to the public under the GPL license...(If you are going to do a product for public distribution. Obviously for your private testing and use you can do whatever you want.)

[Rockatansky]

And you need to release all your source code to the public under the GPL license...(If you are going to do a product for public distribution. Obviously for your private testing and use you can do whatever you want.)

Yes, certainly. If you release plugins made with JUCE in GPL mode to the public, they need to be licensed under GPL and come with all the source code. I assumed that people involved in plugin programming would either know what the phrase GPL mode means or ask about it.

[Frot]

If I understood everything correctly, then GPL mode essentially means: no sign-in to Projucer required, no statistics sent to ROLI, no splash screen. Not 100% sure here, but I don't see any splash screens anywhere.

Ok thanks, I didn't know that was an option. I cannot however release all my code publicly, since it features some code from the books by Will Pirkle. I could, however, compile these into dlls and just link them in.

But at the end of the day, I think the splashscreen is a fair tradeoff to get the framework for free
I'm just glad it's not the kind of splashscreen like in Unity3D where it fills the entire screen before showing the app. This one is kind of acceptable I think