VSTGUI vs JUCE

DSP, Plug-in and Host development discussion.
Frot
KVRer
7 posts since 23 Jan, 2019

Post Wed Jan 23, 2019 9:07 am

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! :party:

quikquak
KVRian
530 posts since 6 Aug, 2005 from England

Re: VSTGUI vs JUCE

Post Wed Jan 23, 2019 9:51 am

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
KVRian
1210 posts since 10 Jun, 2004 from Inverness, Scotland

Re: VSTGUI vs JUCE

Post Wed Jan 23, 2019 10:13 am

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/
.................................
"Hell is other People" J.P.Sartre
.................................

Karbon L. Forms
KVRian
1210 posts since 10 Jun, 2004 from Inverness, Scotland

Re: VSTGUI vs JUCE

Post Wed Jan 23, 2019 10:21 am

quikquak wrote:
Wed Jan 23, 2019 9:51 am
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)
.................................
"Hell is other People" J.P.Sartre
.................................

Big Tick
KVRAF
3256 posts since 29 May, 2001 from New York, NY

Re: VSTGUI vs JUCE

Post Wed Jan 23, 2019 10:29 am

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
KVRer
7 posts since 23 Jan, 2019

Re: VSTGUI vs JUCE

Post Wed Jan 23, 2019 11:15 am

Cool thanks for your answers!
Karbon L. Forms wrote:
Wed Jan 23, 2019 10:13 am
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!)

Karbon L. Forms wrote:
Wed Jan 23, 2019 10:13 am
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.)

User avatar
Rockatansky
KVRist
288 posts since 3 Jun, 2017

Re: VSTGUI vs JUCE

Post Thu Jan 31, 2019 8:02 pm

Frot wrote:
Wed Jan 23, 2019 11:15 am
(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.
Confucamus.

Xenakios
KVRian
1196 posts since 9 Sep, 2005 from Oulu, Finland

Re: VSTGUI vs JUCE

Post Fri Feb 01, 2019 4:31 pm

Rockatansky wrote:
Thu Jan 31, 2019 8:02 pm
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.)

User avatar
Rockatansky
KVRist
288 posts since 3 Jun, 2017

Re: VSTGUI vs JUCE

Post Fri Feb 01, 2019 8:51 pm

Xenakios wrote:
Fri Feb 01, 2019 4:31 pm
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.
Confucamus.

Frot
KVRer
7 posts since 23 Jan, 2019

Re: VSTGUI vs JUCE

Post Sun Feb 03, 2019 10:22 am

Rockatansky wrote:
Thu Jan 31, 2019 8:02 pm
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

Return to “DSP and Plug-in Development”