Cannot resolve JucePlugin_Name

Getting Started
1

I started a new project with the procuer which is an audio plugin. I am working on a Linux machine with VSCode. So I included the path to my JUCE/modules folder and it can also resolve all the modules. But I have an error in the PluginProcessor.cpp in the getName() method where it returns JucePlugin_Name and it says that JucePlugin_Name is undefined. But building the plugin works. Is there another path that I need to include?

2

Okay, when I add #include “JucePluginDefines.h” to the PluginProcessor.cpp it works…

3

A lot of these kinds of issues depend on your working methodology. Are you fixing an error of your IDE configuration - such that it cannot find files it would parse and index to provide intelli-sense, for example, or are you getting mired by your Build environment, your project directory setup/structure, or … something else?

Do you have the ideology that you should just have “one” JUCE folder on your system somewhere, and it’ll be the JUCE version you will use for all your projects - or are you comfortable having a local JUCE/ repo cloned specifically to your project, so you can manage it at a per-project basis?

Things get weird with IDE’s when you use out-of-tree resources (such as setting up a global JUCE path) instead of just including all your necessary components in the project base folder.

This is easier for an IDE to manage/parse:

.
└── MyCoolProject
    ├── JUCE[*]
    └── Gin
    \ (&etc.)

 (*-or more often lately, tracktion_engine, which brings its own JUCE\...)

… than this:


.
├── Gin
├── JUCE
├── MyCoolProject
├── MyCoolProject2
└── tracktion_engine

I would strongly advise you to just have JUCE/ cloned inside YourCoolProject/ as a module - this way, your IDE will have a base tree to parse, including everything, without there having to be a separate configuration option for ‘extra trees to scan…’ (Don’t forget to always use the project-specific Projucer when you need it, also)

Anyway, good luck whichever path you take …

(PS- I’ve been along these paths, and have ended up with CMake-all-the-things, CLion for development, and pamplejuce for Builder responsibilities … and all along the way, path issues have been important to manage, just sayin’ …)

4

Cool Thanks! Will try it with copying the JUCE folder into my cool project =). So I will copy the whole thing? Including the Projucer and stuff when going this route?

ATM I am reading the audio programmer and when I open the finished project in vscode with the same path configurations it can resolve the JucePluginDefines without the need to add it manually.

And atm I have no experience with CMake. But I read about it in many places that there are advantages over the projucer. Will look into it at some point for sure!

5

Think of JUCE as a module for your project, put it alongside your main project resources (but not in your project-specific Source folder) and include it as a dependency in your project. Any time you start a new project, simply repeat. This way you can have some projects on older versions of JUCE if they need it, or whatever. Maybe you want to start a new JUCE project to see whats up on the develop branch, and so on …

That JUCE/ subdirectory will have sources, and as well - yes indeed, the Projucer, which you should build and run straight after cloning the JUCE repo … and … for as long as you use .jucer files … you’ve got a Projucer for the JUCE for the project .jucer, right alongside all your other project resources.

Some people don’t like this approach since it puts binaries in the repo, but some people DO like it, for the same reason. It means your repo will be as close to “reproducible” as possible …

Either way, as you’re getting along, all of this is just for the horizon, I’d say … and yeah, one of these days, give the CMake approach a look. Don’t forget GitHub - McMartin/FRUT: Building JUCE projects using CMake made easy … :slight_smile: