@Lindon Yes you spotted both of the main issues:

1. JuceHeader collision. Previous versions used #include "../Binaries/JuceLibraryCode/JuceHeader.h" which was fine for the DLL, but exporting to VST3/AU caused the JuceHeaders (project info like companyName, versionString, etc.) to be pulled in twice. Solution is just to use #include <JuceHeader>

2. .cpp.inc is resolved on all Fx to just .cpp (it was a leftover from the batch compile I ran).

3. A handful of effects couldn't be compiled together — some of the amp/saturation nodes (the ones based on a shared __Gain_H template) and a few of the k-reverbs. Individually they were fine, but combining them caused build errors. It came down to a couple of effects accidentally reusing the same internal names behind the scenes, so they stepped on each other once everything compiled together. That's now sorted out, and the full set compiles as one.

The repo is up-to-date now and should be more stable.

@Chazrox Nice. I recall there was actually a fairly decent Harmonic Exciter made in scriptnode shared on the forum a while back.

You're also welcome to plumb the Hise-fxLibraries . It's mainly C++ libs, but there's also a Faust one.

@Oli-Ullmann I reached out to Ableton last year for a NFR copy of Ableton 12 to test plugins and they were more than happy to accommodate me. Worth a shot ;)

@observantsound I think the HISE CLI will one day handle this: https://github.com/christophhart/hise-cli . So you can point an AI agent at HISE and have it build the module tree.

Likewise, you can crack open the .xml and copy/paste whatever is happening with one sampler to all the others, but you will need to update the names and everything. You can also just let an AI do that (but it can become problematic if it becomes corrupted).

I believe your intuition was correct though, using the builder is meant to solve this but it is buggy atm.

It can become tedious work though, a copy/paste feature for the module tree would be a nice addition.

@Lindon Given that Rhapsody uses it (and I see some people posting issues with it actually, is this the same issue?), would david's system be an option for you here?

@dannytaurus

Agreed the Expansion system deserves quite a bit more swearing. I think it could use a pretty serious overhaul especially on the UX side when developing.

@David-Healey Yup was trying to save over the factory preset

I used the drag n' drop feature for the sample install. Worked without an issue, it also removed the .hr1.

@David-Healey I like the LAF

The only thing I managed to break: Holding a note and adjusting the Transpose caused a hanging note. I'm assuming that's more of an issue with the MIDI module in HISE and it's not a really big deal anyways. Personally I keep a MIDI kill switch on the UI for these reasons.....

Also, the save button on the Preset Bar doesn't work for me (no alert window, doesn't do anything).

No other issues to note.

I tested on Mac and installed the samples via the VST3 in Ableton.

As @David-Healey says, the only file you need to copy over are the scriptnode network files (.xml) in the DspNetworks subfolder. Most of that other code is autogenerated when you compile the dll. So if you open them in the text editor you'll see the point to a path related to your project. I think I touched on some of this here.

Copying over the xml and recompiling in a new project is the way to go!

@Chazrox Yea that won't resolve it. The no-space rule in naming files is somewhat ancient at this point, most of the time the compiler will resolve it.

You also don't need the Custom Node Path set.

The Export or Setup Wizard I believe has been abandoned which is why it's no longer there.

@Chazrox Yea sorry I couldn't be more helpful, it seems like my initial suspicions were wrong here.

Another thing to try, I notice your main folder is called "HISE Projects". Sometimes a space like that can throw the compiler off (a better name is just HISEProjects, no space). This probably isn't the issue but worth trying.

When you hit that compile to dll button in HISE, there is a bash script that runs which sets up projucer and creates an xcode project, then compiles the dll. It's in DspNetworks/Binaries/batchCompileOSX.sh

For me it looks like this:

#!/bin/bash
PATH="/usr/local/bin:$PATH"
chmod +x "/Users/ernest/Github/HISE/JUCE/Projucer/Projucer.app/Contents/MacOS/Projucer"
cd "`dirname "$0"`"
"/Users/ernest/Github/HISE/JUCE/Projucer/Projucer.app/Contents/MacOS/Projucer" --resave AutogeneratedProject.jucer

set -o pipefail
echo Compiling  DeleteMe ...
xcodebuild -project "Builds/MacOSX/DeleteMe.xcodeproj" -configuration "Release" -jobs "8" | "/Users/ernest/Github/HISE/tools/Projucer/xcbeautify"

But it sounds like whatever issue you are having fails before this key file is ever even generated.

@Chazrox Quite possibly. You could launch the xml in a code editor. Copy and paste the version I sent then try to compile again.

@Chazrox Yes, maybe just double check. I'm not sure this is the case or if because I am launching the file you sent from the web.

@Chazrox said in Build Failed - Missing JUCE 'modules' ?:

script_fx.xml

So I used your snippet and saved it to my project. The result is almost the exact same:

<?xml version="1.0" encoding="UTF-8"?>

<Network ID="script_fx" AllowCompilation="1" Version="0.0.0">
  <Node FactoryPath="container.chain" ID="script_fx" Bypassed="0" Name="script_fx">
    <Nodes>
      <Node ID="gain" FactoryPath="core.gain" Bypassed="0" Name="gain">
        <Parameters>
          <Parameter MinValue="-100.0" MaxValue="0.0" StepSize="0.1000000014901161"
                     SkewFactor="5.422270774841309" ID="Gain" TextToValueConverter="Decibel"
                     Value="0.0"/>
          <Parameter MinValue="0.0" MaxValue="1000.0" StepSize="0.1000000014901161"
                     SkewFactor="0.3010300099849701" ID="Smoothing" TextToValueConverter="Time"
                     Value="20.0"/>
          <Parameter MinValue="-100.0" MaxValue="0.0" StepSize="0.1000000014901161"
                     SkewFactor="5.422270774841309" ID="ResetValue" TextToValueConverter="Decibel"
                     Value="0.0"/>
        </Parameters>
      </Node>
    </Nodes>
    <Parameters/>
  </Node>
</Network>

But yours is missing the formatting version: <?xml version="1.0" encoding="UTF-8"?>

Why I do not know!

@Chazrox Hmmm. Can you attach both a snippet with the scriptnode network, then also post the .xml from the DspNetworks/Networks?

@Chazrox You are trying with JUCE 6 right? The JUCE 8 integration is still very buggy so I wouldn't recommend building with JUCE 8.

@Straticah I was poking around the HISE source code and saw this was added recently:
https://github.com/christophhart/HISE/commit/488ad099eeb20a0f14073fefb1971689ae8578d4

Possibly the fix you were looking for but I haven't tested myself yet!

@Chazrox If I had to guess right now it looks like the script which HISE runs to autogenerate the template for the dll is failing you. Does the version of JUCE you used to create HISE match the JUCE version in the project settings?

@Chazrox That is indeed an odd error. After you try the compilation, do you get the Binaries folder showing up in DspNetworks?

So YourProject/DspNetworks/Binaries

If so you can try launching and running this directly in XCode:
DspNetworks/Binaries/Builds/MacOSX/YourProject.xcodeproj

Building from xcode will give you more informative error reports.

I'm looking for documents and examples to guide you and I am seeing this is rather poorly documented.

Basically DspNetworks folder works like this:

DspNetworks/Binaries: The compiled DLL. When you compile networks to .dll, HISE is launching and creating a mini-project of just your FX networks, so it contains a .jucer, XCode or VisualStudio file, etc. DLL (Dynamic Link Library) is, to put it crudely, a pre-written and formatted library that contains the DSP code which HISE can load at runtime (for example, load into the HardcodedMasterFx). You can simply delete the entire Binaries folder before compile to DLL for a fresh start (in fact it is a good idea). More info here: https://docs.hise.dev/scriptnode/manual/third_party.html

DspNetworks/CodeLibrary: I don't look here much, but it's usually where a lot of the faust and snex networks are saved to.

DspNetworks/Networks: Where scriptnode networks are saved as .xml. So you can actually look at these in a code editor and see the same structure flow and module settings (it is fairly human readable). This is what is saved and recalled when you are launching networks (it's very similar to how a User Preset works).

DspNetworks/ThirdParty: Mainly for C++ files if you are working that way. I think Snex headers are stashed here as well (I can't remember). You'll also notice HISE will autogenerate headers depending on what you are using, example for Faust.

AdditionalSourceCode/nodes: This is also important. When you go to compile networks you see the menu below. Basically it is autogenerating some headers that are stashed here for when you are ready to compile the entire project. They help link the compiler to the necessary DSP files. You don't really ever need to bother with this folder, but for a completely fresh build, you can just delete the "nodes" folder before compiling the networks to DLL.