@scottmire I believe you are on the most fruitful track if you want to leverage LLMs for custom DSP development in Scriptnode. AI is still not at a point where it can function as a replacement for DSP knowledge, but it can be a very helpful tool for filling in certain gaps. AI models have a tendency to cut corners and get to a solution as fast as possible rather than considering if it is really the right solution in a specific context (I think griffinboy's point covers this quite well).

Personally I like to start with research articles and open source github repos and either read or skim them to gather context about a particular topic. Identify which solutions work in your context, ask here about it or on other forums, and for the aspects which you find difficult to understand you can possibly consult an LLM (pinch of salt as always).

That being said, letting an AI autonomously work on a particular task and being able to verify the output is the most critical part. Specific harnesses and tests you can run and trust are quite critical here. This is true whether it's vibecoded or human written. I rely heavily on tools like HART. Pluginval is useful for validating your plugin, and PluginDoctor is very helpful for visualizing and measuring your results.

I also believe the hise-cli can construct scriptnode networks in realtime though I haven't really tried it as I prefer creating Thirdparty C++ networks.

@resonant is it an issue with the Neural node or the global cables? I haven't used the neural node much so I don't have much advice there.

I think the issue is as Christoph noted before: HISE tries to load the network in the hardcoded FX before the first script compilation.

The easiest way to recover your project would be going directly into the .xml and cutting the HardcodedMasterFX out of the project. Then reload the xml and resavee it. Add your Neural node FX back in. Also just comment out all your scripts first so the project can load, then slowly add them back in.

@David-Healey Oh yes of course they collect all the data. It's exactly as @dannytaurus mentions, it's more to isolate personal info and letting Claude loose on your local machine instead of having to put gaurdrails and security measures up. There's also a lot of trojans sneaking in from github repos these days....

@resonant If you have a dedicated system, I recommend (or at least prefer) to run things locally. It offers some advantages, though I'm not sure what the current state of running Claude in the browser looks like (perhaps it's equally as good at this point).

There's a lot of ways you can configure things. You could also use the desktop app, but I don't personally prefer this since you are losing oversight of the project you set up. In my experience, working with claude from an IDE like VisualStudio Code, or just running it in the terminal, is a lot more powerful.

That being said, it doesn't really matter how you set things up. There's no tutorial since it's fairly new and I think it depends on your preferred way of working. I write a lot of C++ DSP and work in JUCE fairly frequently, so I prefer the IDE.

Just dive into it. Clone those repos I sent you. Open Claude (browser, ide, terminal, desktop app, whatever). Direct it to all the repos: HISE, your project, the CLI, MCP, LSP, and ask it how to setup and configure everything. That's actually one of the benefits to an LLM. Ask it to explain things and how best to configure your workflow. It can guide you. If you have a dedicated machine it's all the better since you don't need to worry as much about permissions and sensitive information getting leaked.

There's a lot of Youtube videos online about using Claude Code. Generally they are pretty garbage. You can learn a lot more by following Antrhopic's own documentation and courses.

@resonant Maybe the best place to start is to familiarize yourself with using Claude in an IDE like Visual Studio Code. Anthropic actually has some decent tutorials on using Claude Code as well.

Next, the best applications of using Agentic coding in HISE is via:

• MCP (Model Context Protocol). It's the most valuable tool since it gives Claude a structured way to explore HISE and the scripting protocol instead of making things up or guessing.

• CLI. A command line tool, it allows you and the agent to control HISE from the command line. So it can do things like add components to the UI.

• LSP The language Server Protocol. basically helps Claude not butcher or hallucinate HiseScript.

So I'd suggest just cloning those, then launch Claude from terminal or inside an IDE, direct it on the repos and ask it to set everything up for you.

@Chazrox Nice work I'm looking forward to trying this! Have you considered making it compatible with JUCE projects? You'd hit a much larger audience, plus the HISE graphics API is nearly synonymous with JUCE's API (at least for JUCE 6.0, there's much more available in JUCE 8/9).

@Lindon @griffinboy 's method is essentially how I do it too (measure them beforehand while working on the core DSP). But to do it from within HISE is not so hard either:

You can leverage Engine.get/setLatencySamples to do this.

I discussed it here, and I believe someone developed an automated process for it on the forum elsewhere (I can't find the link, or perhaps I am going mad)....

I'm not terribly confident the HISE CLI/MCP could handle this, but you could direct an agent to load each network, one at a time, into a HardcodedMasterFx. Each time get it to recompile with:

Console.print(Engine.getLatencySamples);

Collect all those values, then anytime that network is loaded in, use Engine.setlatencySamples to update the host. In my experience these two functions will work both when the plugin is loaded, and during real-time processing (presumably at blockrate).

Likewise you could turn an Agent onto the source code and read the DSP pieces (as griffinboy suggested), but in a complex network, done for all 133 FX, I picture that leading to more errors long-term.

*Note: I've never tested this method thoroughly enough. Possibly some hosts are not going to support dynamic changes to the latency reported *

@ustk I’m away from my system, but i did this a few years back (mono and stereo with sidechain support for VST3/AU/AAX). I had to modify the HISE source code at the time, perhaps this is built in now.. Once I have a moment I’ll share with you the process ;)

@lalalandsynth Not to my knowledge. But the webview presents a whole series of challenges by itself. If it's a simple LAF for a knob, or paint routine for a panel, then CSS is much more worth investigating.

@lalalandsynth Yea CSS would be the way to go. HISE does indeed use melatonin_blur , it's negative performance effects have been noted on the forum before. Possibly updating it to a newer version would help, but I personally dropped it in favour of CSS or using a Webview.

@Chazrox There's always the HISE snippet browser which I think sort of died off but was a very useful concept. It would also help to see the HISE Asset store ship soon, but there are certainly other priorities. Agreed it would be nice to see more user engagement.

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