@blush It's listed under the PathTypes section here: https://docs.hise.dev/ui-components/floating-tiles/plugin/draggablefilterpanel.html

https://docs.hise.dev/images/custom/filterpathtypes.png

@David-Healey Nice good idea, I assume the same is true for the JUCE submodules (JUCE 8 vs 6)? That can be a real point of breakage for a lot of people.

I see it does set everything up for you. This is pretty sweet for anyone new to the HISE framework!

@Christoph-Hart Ah that explains some previous issues I've experienced with fftw. Nice addition for the CLI, does the user need to have a copy of HISE already or does the wizard take care of that as well (I.e. just setup hise-cli and run /setup ).

@David-Healey Nice thank you, sometimes I have client's asking me to help with their setup so it's simpler to point them towards your tutorials rather than walk them through it step-by-step.

May be one for @David-Healey , what is your most up-to date build instructions / tutorials for building HISE from source? Ideally with Faust and/or other dependencies like FFTW.

@ustk said in Claude's ugly code:

@David-Healey You can ask Claude to analyze your previous project styles once for all so it automatically applies it next time

Definitely you can, and it often shows up as a big improvement. I find after time that Claude, Codex (probably other agents too) start to "drift" towards their preferred style of coding anyways. They also have a tendency to over-comment and use special characters which HISE doesn't support. Example:

// ── Backend ─────────────────────────────────────────────────────────────

Which renders like this:

I also see it drop things in scripts that are outside a namespace, and the namespace does not always match the script's name. Example file: HiseScriptStandardsForMyAgents.js:

namespace ScriptStandards
{
    // Rules for following strict scripting standards
   inline function iDontFollowTheStandards();
    // ....
}

iDontFollowTheStandards();

// End of HiseScriptStandardsForMyAgents.js:

I wonder if more rigid guidelines around the HISE scripting standards in the HISE-MCP would help, but most important caveats are already featured in style-guides.ts and in the guidelines. Seems like Christoph did a bang-up job already and agents just have a tendency to cut corners over time to in order to complete the task.

@David-Healey said in Claude's ugly code:

This is some code Claude gave me

if (key == "midi" && isDefined(data.midi))
    ma.setAutomationDataFromObject(data.midi);
else if (key == "macro" && isDefined(data.macro))
    mh.setMacroDataFromObject(data.macro);

This is how I would write it

if (!isDefined(data) || !isDefined(data[key]))
    return;

if (key == "midi")
    ma.setAutomationDataFromObject(data[key]);
else
    mh.setMacroDataFromObject(data[key]);

Just sayin

Hey Claude, please update your behaviour to script more like @David-Healey . Don't make any mistakes this time.

@pratitghosh Nope your scriptnode networks exist as .xml files.

So this folder: HISE\Project_Strip\Channel\DspNetworks\Networks

Copy all of those over and recompile the DLL in your new project.

@digi said in UPDATE // NEW: Online Knob Builder for HISE!! // SVG's has entered the chat ! =):

Utilised https://marketplace.juce.com/products/melatonin_blur and got it rendering in JUCE nicely

You may need to double check but I believe this library is already integrated into HISE and it is how HISE uses blur and shaders. However, I've seen post on here and the JUCE forum regarding this library having performance issues (so worth doing a quick search before implementing it).

@paper_lung I believe the Macro system is something of a "deprecated" system, and it's pretty limited in terms of customizability:

https://forum.hise.audio/topic/1785/documentation-on-macros-anywhere/8

Two options:

1. Roll your own system via HISE ]script.
2. Edit the source code.

Personally I don't see any issues with the Macro System, I think it's pretty good and just needs a bit of updating. More API calls, a few QOL improvements, and it is actually pretty useful. A few features I'd like to see are mainly in the FrontendMacroPanel like being able to set a skew amount on the mapping and changing the parameter's to display the parameter text rather than the parameter ID (Instead of "knbReverb", it will just display "Reverb").

But I think your request is quite reasonable. Depending on the interest here I could make some edits and pr request with these features.

@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!