faust2juce creates a single cpp file along with a jucer file.
Here are the changes I made:
This one I did otherwise you can’t read the text.
Here are a few of the compilation errors I’m getting.
It looks like all references to “dsp” cause an error, e.g.
I’d attach the source but it looks like I can’t do that.
That is a great start, so far you did exactly what I was going to write.
It seems the project is importing the juce namespace and subsequently there is a namespace dsp from juce and a type dsp from faust.
I remember having read that problem, I’ll dig it up. Since I didn’t use faust myself yet, I didn’t really memorise it.
Try to use the -scn foo option (-scn --super-class-name specify the name of the super class to be used instead of dsp.)
So something like faust2juce -scn FOO foo.dsp
Thank you Stéphane for taking the time to answer here. That’s much appreciated, I know there are so many places where faust is used.
@Digital_Larry, please let me know if that solves your problem.
If there is anything I can do to make the integration more smooth please let me know.
Thanks, I’ll give this a try. I noticed that the compilation errors around “dsp” happened simply when I added the GUI magic module to my JUCE project, before making any explicit code changes. I’m just going through this one step at a time. Eventually I will probably have no choice but to understand all the ins and outs of VST and JUCE internals.
I rebuilt the CPP using the -scn flag as suggested by @sletz (hey, are you following me? 
) and the compilation errors disappeared. Now to make all the other changes again to enable the functionality.
OK thats is nice to hear, so I’ll probably add -scn base_dsp by default in the faust2juce script.
Okay, I regenerated the CPP file from Faust using the -scn flag and it overcame most compilation errors. I’m left with just a few and here they are:
Here’s the full diff between the most recent Faust-generated CPP (right) and after my hand edits (left).
Maybe I shouldn’t have deleted this. I’ll put it back.
Okay, that cleans up the C2600 error.
Great, it is getting there.
From PGM side you can (read: should) remove the foleys::MagicProcessorState. There is already one in the foleys::MagicProcessor you inherited. And you can access it in your processor as magicState.
Hope that works now.
It seems you removed the getStateInformation and setStateInformation from the implementation, but not from the declaration. You need to remove them from the header as well. Those methods are declared and implemented in the base class foleys::MagicProcessor already.
Getting somewhere. I opened Ableton Live and added my plugin. It has a blank canvas. The GUIMagic popup was hidden behind Live but I found it.
Nice! Now you can start dragging things into the Gui-Tree. But there should be a root node… dough.
I need to have a look. I didn’t check with a new plugin after the latest changes. My apologies if it doesn’t work. I’ll fix that asap.
Yeah, there’s nothing in GUI Tree at the moment. I was able to add some sliders but there’s nothing to connect them to.
Here’s the parameters as seen by Ableton Live:
Here’s how the Faust code looks in FaustIDE:
Well, a quick fix if you want the default GUI you can add in your constructor:
auto defaultGUI = magicState.createDefaultGUITree();
magicState.setGuiValueTree (defaultGUI);
That should also bring up all parameters as sliders. You can start reorder things there and play around.
If you saved your tree using the file menu, you can add that xml file to the binary data and call instead:
magicState.setGuiValueTree (BinaryData::magic_xml, BinaryData::magic_xmlSize);
FTR: this post is the most uptodate explanation how to use it:
I know I need to record an updated video as well, so poeple don’t look at the old ones.