First try, no luck, nothing in the GUI

Hey, me again, you can expect to have me lurking here like every day, as I try to find my way into PluginGuiMagic. Must admit I’m a newcomer in JUCE as well, though having a serious development background and having done several VSTs already.
The reason I’m here is by the way as, having little knowledge about JUCE, I’m looking for efficient ways to design my UI and focus on DSP dev. I’ve previously been using BlueCat’s Plug n Script that is a full generator where UI is designed as an XML file, but I’ve come now to the limitations of it (mainly the hard limit of 48 params for any plugin which is alas a showstopper for me).

I’ve tried to mimic almost exactly the FoleySynth in my first attempts, but I can’t seem to get any of my parameters to show in the UI, though they should show automatically using this in my processor’s constructor:

ModinatorAudioProcessor::ModinatorAudioProcessor() :
treeState (*this, nullptr, ProjectInfo::projectName, createParameterLayout()), LFO1(treeState)
{
auto defaultGUI = magicState.createDefaultGUITree();
magicState.setGuiValueTree (defaultGUI);
}

In your second video you use this:
foleys::MagicProcessorState magicState { *this, treeState };
But this line doesn’t compile as the constructor for magicState now only has one argument.
And in FoleySynth this line is anyway absent, so I suspect this is now already initialized in the MagisState class whihc my processor inherits from.

I must admit I’m really confused now, and would really like to have an up to date template project with what you thing the current good practices are, as I understand that both JUCE and PluginGUIMagic are quickly evolving…

Thanks, looking forward to great stuff from you !

Yes, that is spot on. The magicState is already declared in the MagicProcessor.
It is protected (i.e. visible to inherited classes), so you can access it directly from your processor class.

Do you get the toolbox window to edit the GUI?

Yes I do, in the meantime figured out I actually needed to add the parameters for them to appear (they seemed they had a default layout in your video so I thought they should appear at first launch).
Now I can add them, but I’m facing other issues for classes that have multiple instances (LFOS typically),
each of them have its params added like this:
auto frequency = std::make_uniquejuce::AudioParameterFloat(paramFrequency, “Frequency”, juce::NormalisableRange (0.0f, 200.f, 0.01f, 0.25f), 1.f);
layout.add (std::make_uniquejuce::AudioProcessorParameterGroup(paramFrequency, “Frequency”, “|”, std::move (frequency)));
Some of these params should be unique, no ? Should I rename some, or the make_unique ensures I don’t need to ?

Sorry, as I probably have many questions related to JUCE, not to PGM, it’s quite messed up for now.
My next point would be to have filmstrips for my knobs, I understand there are various ways to do that but none is provided here, right ?

Thanks !

Yes, the parameter IDs should be unique.
The make_unique is a red herring, that has nothing to do with unique IDs. TBH I don’t know why it is called unique_ptr, but that is just a smart pointer that manages the lifetime.

The FIlmStrip knob is on my list. I would want to use a LookAndFeel, but the LnFs are shared amongst many Sliders, so I cannot have the FilmStrip image in the LookAndFeel.
Like I said, it’s on my list.