I want to hire a programmer to make an audio plugin for Studio One.
Since I read that JUCE is good for audio programming, I thought this would be a good place to ask a few questions.
So which programming language would be best to make the plugin?
I’ve heard that C++ is good and also compatible with JUCE.
But is there a better programming language for this job?
Just to be clear, my platform is Windows 10.
The plugin has to work inside Studio One which is a DAW, and ideally should be also compatible with other DAWs like Cubase, FL Studio etc.
I believe it will need to be compiled into a .dll file
If it’s saved in the right folder, Studio One will find it and load it up.
Now, the plugin will work with MIDI only, not actually touching the audio.
So my questions are:
Would the programmer need to know JUCE?
Does JUCE make this kind of job much easier?
If they only know C++, would it be much harder for them?
Would it be worth them learning JUCE from scratch?
Sorry if these seem like dumb questions, but I have done some searching but can’t find this kind of information out there.
I’m not ready to hire just yet.
These are just preliminary questions.
Short answer is yes, the use of JUCE is very widespread in audio / music software.
A few issues you might run into:
The VST2 license is no longer available for new developers (which compile into .dll files), VST3 plugins compile as .vst3 files, but im sure your host has probably set up compatibility with the new standard by now.
I might be wrong about this but I’m not entirely sure about MIDI processing capabilities with the VST3 standard, there have been a few threads on the forum regarding it, such as this one.
I started learning C++ with JUCE, and I don’t think that it would be too difficult to learn if one is already experienced with C++ as it’s just a framework.
If I find a C++ programmer who hasn’t used JUCE before,
are there any specific advantages it has over other platforms that I can tell them about,
particularly for an audio plugin?
If they have experience with other audio related applications there shouldn’t be too much of a learning curve; the only exception IMO would be if you hired a programmer who has no experience with DSP (or the MIDI standard in your case), which would require a bit of learning, but if you found someone on the JUCE forum it probably wouldn’t be an issue.
Hi there - @momentumm 's answers appear spot on - C++ programmers with even mild DSP/audio programming experience will enjoy JUCE as it allows users to focus on what they’re building without getting bogged down in low-level buffer grabbing stuff (or really dreadful SDKs like older steinberg ones).
As for the VST2 comment, my limited experience testing on Studio One has left me with a good impression regarding VST3 loading so I wouldn’t worry much about that.
One thing to note when using JUCE is that, part of the goal of the JUCE framework is to allow for the development of crossplatform, easily transportable code so when you make a plug-in, it should (theoretically) work in most DAWs. There are various quirks you’ll find amongst different DAWs (no fault of JUCE) but you WILL NOT have to rewrite your plug-in for each OS, DAW, etc…
Best of luck!
You seem to understand this area.
I’m still trying to figure out the best path and this is all new to me.
Today I read this comment on Midi.org
“VST 3.7 introduces the VST 3 Project Generator that further facilitates the entry into the VST development world. The VST 3 Project Generator allows users to create a VST 3 plug- in project with just few clicks, which can then be used as the code skeleton in Xcode or Visual Studio.”
So would I be right in thinking that the order of a plugin’s development would be:
- VST3 Project generator
- Visual Studio
- JUCE framework.
Can step 3 be skipped, or does JUCE create the wrapper that is essential for compatibility with the DAWs and platforms as you mentioned?
JUCE is not the only way for cross platform development.
I think Steinberg aims to create wrappers making vst3 plugins run on other APIs as well. They also have the vstgui as cross platform gui, but I haven’t met anyone who enjoyed using that (I didn’t use it myself), rather the opposite
Another alternative is iPlug2 by Oli Larkin.
There might be more.
My personal opinion: JUCE is an excellent choice, but if you got someone with a strong background in another choice it’s worth hearing them out. But keep in mind if you need to replace that person later, it might be easier to find another juce person…
Not exactly. JUCE comes with a full implementation of the VST3, VST2, AU and AAX interface, so you don’t ever need to write something VST3 specific. Instead you only interface with the JUCE API directly which acts as another abstraction layer which then allows you to generate plugins for all the formats mentioned above from the same code. Therefore, you also don’t need to create a basic VST3 project with the VST3 Project Generator as a starting point.
With JUCE you’ve got two options here, the first one is the Projucer. It’s a tool shipped with JUCE that also creates fully configured Visual Studio or Xcode projects which contain all the basic settings to get startet with building a plugin. It’s more or less comparable with the VST3 Project Generator from that point of view. The other option is a bit more advanced, which is CMake. CMake is a very widespread way of managing large scale C++ software projects in an IDE and platform independent way. So instead of generating e.g. a Visual Studio project with the Projucer you can also do all this with the CMake scripting language and then generate projects for nearly every possible build system out there from that script (Visual Studio included, of course). If you hire a professional C++ developer, chances are high that they are familiar with CMake and it allows them to chose their tools of choice to get the job done.
Wow, you have been so helpful.
I have reached so many dead ends in my enquiries.
This now gives me a path forward.
I have seen a Projucer demo briefly, and it seems to be made for common DSP plugins.
My plugin won’t be dealing with DSP and is not standard at all and will have to break many conventions to even work.
I can’t license a VST2 plugin as Steinberg won’t allow it anymore, so it has to be VST3.
However, Steinberg has announced that VST3 will not deal with MIDI CC data and it’s up to the host to do that.
Since building an entire DAW is going to be too expensive for me, I need a workaround solution.
I think the CMake option sounds like my best bet.
So do I have the option of using CMake with or without JUCE?
Would I build it using CMake and then apply to Steinberg for a VST3 license?
I would want my VST3 plugin to be proprietary and not open source.
The Projucer generates JUCE projects. JUCE can be used to create DSP or MIDI plugins, or standalone apps. The Projucer can generate projects for any of these.
CMake is just a build system configuration tool. It essentially does the same tasks as the Projucer - you can use it to set up JUCE projects. But CMake is not specific to JUCE, any C or C++ project can use CMake.
There’s a way to get cc data into a vst3. It’s gross but most of us who write vst3 directly do it and juce does it too. If you need midi cc data in a vst3 and write your plugin in JUCE this detail will be thankfully hidden from you
(Input and output are two different things; I see from another thread you may want output and @eyalamir s answer there is spot on)
Thanks for weighing in on the discussion.
Are you referring to creating 128 * 16 proxy parameters in order to receive MIDI CC?
Juce does that for you
Oh and if you want to see an example of an opensource (GPL3) juce vst3 plugin which generates midi, stochas is a probabilistic step sequencer and is up at github.com/surge-synthesizer/stochas and at stochas.org
It’s in the juce vst3 wrapper somewhere. Surge used to do it before we ported to juce too.
The point is juce does it and hands you a midi message in its buffer so you don’t need to know where really.
Do you know if the order of MIDI CC events is preserved by this method?
That seemed to be the main issue with VST3 on the Steinberg forums.
I have not tested that. From knowing the vst3 api I could see how they would be but from having run a vst3 in a lot of daws I could also imagine they may not be consistently. Try it is my advice.