Exporting

3.1 The CMajor classes

The export is modelled by objects rather than string templating, so it can be extended:

Your UI primitives become CMajor endpoints and view elements automatically — a PhHSlider in the patch becomes a control in the exported interface, with the range you declared.

3.2 Polyphonic wrapping

A Phausto patch is monophonic by construction. To make a CMajor instrument polyphonic it has to be wrapped in a voice allocator, and Phausto generates that wrapper:

4.1 Plugin types

The type: argument is an object, not a string. It answers everything that differs between an effect and an instrument (the buses, the MIDI handling, the flags the host reads, which controls become parameters), so the exporter never tests which kind of plugin it is writing. A misspelt type fails when you accept the code, not halfway through an export.

The buses are stereo, and a host may also choose mono. A mono patch is fine either way: the generated PhaustoChannelAdapter.h repeats the last channel when the bus has more and averages when it has fewer, so a one-channel program feeds both sides.

An instrument is played through three controls named exactly freq, gate and gain, the FAUST convention. A note-on sets freq from the note number and gain from the velocity, then opens gate; the matching note-off closes it. The last note wins, and MIDI is read once per audio block. Because MIDI drives those three, they never become host parameters; the patch's other controls (here the envelope's attack and release) do.

lead := ((SquareOsc new freq: #freq)
    => (AREnv new trigger: #gate; release: #Release; yourself))
    * (PhHSlider new label: #gain).
dsp := lead stereo asDsp.
dsp init.
dsp export2JuceWithName: 'SquareLead' type: PhMonoSynthPluginType new.

4.2 Parameters and the APVTS

JUCE's AudioProcessorValueTreeState is how a plugin exposes automatable parameters to a host. Phausto builds it from the compiled program: every control in the DSP's FAUST UI description becomes one row of a generated table, PhaustoParams.h, holding its id, FAUST path, label, range, default and step. The processor creates its parameters from that table, and the generic editor creates its widgets from the same table, so parameters and controls cannot drift apart.

A parameter's id is its control's short name, and the host displays its label. Once per audio block the processor writes each parameter's current value into the DSP through its FAUST path, so automation runs at block rate. The values are saved with the host session and restored when it reopens.

To see what the host will get without exporting anything:

dsp apvtsParameterControlsFrom: dsp getJSON for: PhMonoSynthPluginType new.
dsp asPhaustoParamsHeaderFrom: dsp getJSON for: PhMonoSynthPluginType new.

4.3 Editors

The editor: argument decides what the plugin window shows. It writes only PluginEditor.h and PluginEditor.cpp: the processor and the rest of the project are the same whichever editor you choose.

fx export2JuceWithName: 'ResonFilter'
  type: PhEffectPluginType new
  editor: PhSkeletonEditorExport new.

In the skeleton, parameters are reached through audioProcessor.apvts, and their ids are listed in PhaustoParams.h. Bind a JUCE control to one with an attachment, declared after the control so that it is destroyed first:

// PluginEditor.h, private members
using SliderAttachment = juce::AudioProcessorValueTreeState::SliderAttachment;
juce::Slider cutoff;
std::unique_ptr<SliderAttachment> cutoffAttachment;

// PluginEditor.cpp, in the constructor
addAndMakeVisible (cutoff);
cutoffAttachment = std::make_unique<SliderAttachment> (
    audioProcessor.apvts, "Cutoff", cutoff);

// PluginEditor.cpp, in resized()
cutoff.setBounds (getLocalBounds().reduced (20));

Keep the class name and constructor the skeleton gives you (EffectAudioProcessorEditor or MonoSynthAudioProcessorEditor, built from the processor): the generated createEditor() relies on both. To generate an editor of your own from Pharo, subclass PhEditorExport and answer headerFor: and implementationFor:; override write:to: to change when the files are overwritten.

4.4 The generated project

Everything is written to Documents/faust2Juce/<Name>/:

<Type> is Effect or MonoSynth, which is also the prefix of the processor class (EffectAudioProcessor). Every file but the FAUST header also has a query that answers its text without writing anything, such as asCMakeListsFor:type: or asPluginProcessorCppAPVTSFor:: inspect those to read the C++ before you export.

The export name also decides how hosts tell the plugin apart:

4.5 Building

You need CMake 3.22 or newer and a C++ compiler: Xcode on macOS, Visual Studio on Windows, GCC or Clang on Linux together with the packages in JUCE's Linux dependencies. Then, in a terminal on any of the three:

cd ~/Documents/faust2Juce/ResonFilter
cmake -P build.cmake

JUCE copies the VST3 and the Audio Unit into the system plug-in folders, and the standalone app stays in build/ResonFilter_artefacts/Release/Standalone/. Rescan plug-ins in your host to find the new one. After a change in Pharo, export again and rerun the script: only what changed is rebuilt.

The script is a convenience, not a requirement. CMakeLists.txt is an ordinary JUCE CMake project that any CMake-aware IDE opens, and the .jucer is there if you prefer the Projucer.