Projucer or not Projucer ? that´s a question

Hello, everyone,
everything is in the title, really… but i would like to know more about different workflows…

As i become familiar with juce (mpore that 100 small and simple vst plugin compile without failure), i am wondering if there is no other way to work. here is my workflow:

Using the projucer, i do my setup, add my new classes, add my ressources (images, audiofiles,etc…), then i complete my code within VS2017…and compile in VST3 format.
=> Every thing goes well !

BUT, i have some doubts, and i would like to clarify before i go for more adventurous and complex plugins:

  • regarding the needed Projucer, is there a way to not use it ? doing everything by hand ?
  • regarding the linked files and classes, where Projucer keeps this info ?
  • regarding existing files, how to not delete my code when i do some modifications thru Projucer? (i was happend to me and i was surprised by it!)

Well, i have no problem to work with Projucer, but still, it can make a mess in my project if i dont understand how Projucer is actually storing data and where.

Please, can you take 5 minutes to give us some precision on that points ?
Thanks a lot, really… when it comes the time to understand fully the mechanism, video tutorials are not enough, and i suppose that on this forum, some users are really advanced and should have some particular and rapid workflow… this is all about.

thx, have a great day
uriel

I’ll try to answer your questions to the best of my knowledge, however there might be others round here that have more experience.

I worked quite a lot with JUCE-based standalone applications running on systems not supported by the Projucer which needed some very custom build scripts. It was more or less straightforward to build up a standalone application using the Juce classes without the Projucer thanks to the JUCE module format. Compiling the base .cpp/.mm compilation units and including the headers of each module, however you should have really understood the juce module format (take a look in the modules subfolder of your juce copy) and how they are used/configured through JuceHeader.h and AppConfig.h.

However I wouldn’t do so if I didn’t need to. Now when it comes to plugins I believe it might get a lot more complex to set it all up by hand, especially if you are building multiple formats like VST3, AU and AAX. Of course it might be possible to set it all up by yourself, but I don’t see the benefit if the Projucer already does that for you.

I get the feeling like you created a project with the Projucer, started coding in VS and then added files and/or changed project settings in VS. After resaving the Project your files were no longer visible? This is because the VS project will re-created every time you re-save your juce project. The idea behind this is that you are normally targeting at least Windows and Mac OS when building Plugins, so you always need to generate a VS and and Xcode project from your juce project. Therefore you use the Projucer to create and modify your projects, not the IDEs themselves. So adding a source file or setting compile flags should always be done through the Projucer, while code editing and compilation will be done in your IDE of choice. All this settings are strored in your projects .jucer file.

However, if you still want to use a completely different approach there is FRUT which let’s you convert a juce project into a CMake based project, giving you all freedom for customization. But I never used it so others might tell you more about it.

Hope that answered some of your questions

FRUT works great for me. If you want to ditch the Projucer, that’s the way to go in my opinion.

1 Like