So as you can see yesterday I've dumped the work of the last month to the repo and now that the CI build goes through it's expected to be compilable on macOS and Windows.

The vast amount of new features included here justify a major version bump, so I would suggest we label the next HISE meetup "HISE Release 5 party" and work our way towards that. My todo list for this includes:

• adding docs for all the new features - they will be more like references and for a high-level explanation for all the features I'll prepare a small presentation for the talk.
• creating snippets & example projects that cover the features.
• fixing bugs & regressions that I encounter when loading up different projects & stuff). It's FeatureStop (tm) at this point so we just need to round the edges of the new things.

But I could benefit from some cloud power here so if you guys could:

• making sure that everything compiles. MacOS & Windows should be covered, but my homies on Linux might want to report back if there is something going on in the land of the free over there.
• making sure there are no regressions. There were a few rather intrusive changes I had to make especially in the modulation system so if you have a project that uses a complex modulation system, please let me know if anything broke there. Especially the bridge between modulators and scriptnode is completely rewritten and there are definitively a few breaking changes that require you to tweak your nodes to adjust to the new system, but I tried to be as backwards compatible as possible and as far as I'm aware there is nothing substantive being removed.
• give me a few suggestions for snippets that cover the new feature set and I'll try to encorporate these suggestions.

PresetBrowser

Bear with me, I somehow got mixed at multiple places and now I had to commit everything to the dev branch, but todays commit history gives serial killer vibes.

There are a few gems in there that will be documented over the span of the next days:

• complete rewrite of the profiling suite (basically a extended version of Perfetto with much tighter integration into HISE). Profile your scripts down to each line of code, quickly check the DSP tree for the worst runtime & see event dependencies across different threads (broadcaster events etc).
• complex sample group manager (the UX is still all over the place and some functions are missing but the basics are there)
• WebSocket server communication for fast data transfer between web view and HISE. Oh and the Webview should now work on Linux too - David let me know if that is the case and what needs to be done to make it REALLY work.

I tried to focus on it not breaking stuff (most of the profiling tools can be completely removed with a preprocessor flag which is disabled by default), but if something behaves nasty let me know. When it's dusted off and documented, we'll call this bad boy HISE 4.5.0...

I suggest we make these things the topics of the next HISE meetup :)

Alright everybody,

it was time to finally bump the version and upload new installers. Enjoy

https://github.com/christophhart/HISE/releases/tag/4.0.0

Hi everybody,

I'm currently profiling a project I'm working on and noticed a rather significant optimization possibility: when there is no signal input, some FX can be suspended until a signal is detected and save some CPU. This might highly improve the idle performance of your plugin, which is important for big DAW sessions.

This is not a new idea (some DAWs implement this already) and in certain parts of the HISE codebase this is already implemented, but now I refactored it to a general system and also allow DSP networks to set the flag.

HiseSnippet 1427.3oc2X0raabCDlqrobkSbRSQP+AnG1C8fCfqgTRZZAxAKaYqTgFYK3UwMsWLn2kxhP6RtkKkrUK58donmys9Zza8Qn25w9J32f1gbWIsqzZAaE2DzJCXHNbH42Ly2LbnZIEtznHgDYUp8vPJx51XmgbU2ZcILNpwtHq6faRhTTocrncFFRhhndHKqkdlVfUokQlOWr0NDeB2kNQDBcjf4ReNKfolHsU0uh46Wm3QayBRo8iq1vUvqI7E8A7rDtLJj31ibJcehVsBXjUw87XJgzQQTzHPmcDdCc5JNiGq+QrH1I9T8fJHGXihEip0k460ZjsFgPV3VSr7khs76iax7XikOwC7tlIrmrhz9.qByCRUtFPxJEjVNFR2C63JYgpIynwysvM3P.oCAb0ogRrtHqeGWS.JvUaFP5QqKgAiWv5Oob4Mrg+8fm1oO2UwDbaAeeghd.e8Gr5OrZoU+wUsmdpNcxcN8wHE99TYtSqitx4sv048CNgJ2vd.wuOcrhf4m0mV7p4Scis5TJJ3M3L0Agzjw0E9dZek96yFAPItM3aunwtDEQGTRjA5ERkJlFNV6RG.r53PTI7tzndJQHvqmI9ALGgWeehJKcRm2jLA3OxDC0AJdDSMLcd00fiUdtbrqJDuGtES41MeLVHGLBdp+MvXRl4Z385zg5pl.vkw0e4hlFV9ZmFtZRZHbl5C+1ICsq+xJ4l.9S3Ij8PIMjHosEs7ICWOhDD5SODv3F1m3Kb64v9d5rYHgwPXGsFq61kv4T+nEIQp3MTwIzgh9JF+zlDkjcNT9b+9ANPYZWZsDzAxrJnyghGWVOVyKbnbOyf+F9jLYE8XqjIqLZxToe6SUmIj8LgijuirVI12GYbxG247Jns88EmUSDDxRXoPLvHqkveXXWAm4pEEqwHjtcfnObHIv8KIQsILeMs1oeDTnv6.tCnr4ZLqBGQkQlMdEb4Mg+.Z99BOXph0ItficXKhpqNeQW6AHmT4ltiIoYvZZdhdKFcMWrWBfXf1z0WxoiOsHR3NOnlstbSAqkRU9IlgpGA4eEhOmFQGom0k3iNRy.zKBoOkXOnAwXspqg6vN+QO7XC2CkwF9fT1PZkt5.+0ClERAy6iiBDBUWp2wgi7DYQ6GaPKP82LGMuwfbQcwQ5HvtF94f2gHsODxhQnIUGaSjmRUQIWWvotwjQiE0vSuMJBuKZbPUKaEb7thREp0vYrQXsRSFO4jmTlsI47ojcwVNJZntNRZ8b5QOK1gkVSsMM5fmYq2tuRD.0IL03Qo.Rwo.xu9pW8aaMCPp9KUmBHF8tbfbWriIzAkUL8ANEf9lpyCCWCmwEyACkv6wIPEPOzLaDJEe7tXw.H.YJdW4ImmkJ9QoRbxp1apTmzY3IbsLH7VXHt1cSyDWCLUHMlxxSslOO8hYoGnpUuQ3oWr0kvSmFiWNfKFu86JYCnna9jrwK8a8d5ecvO+maktpvkWjH2Zd4WxXGgnW.wb+3qcmp2Idxagc.Br4oel6tdeyX6ulLfZ+LJPs0MHVYNu96Otpu9K7J+5uCbUvw2VR3QghnrddZ.qsfqswIBeQD7XG52cntlbZ40DDYtScwV0AiL203PT8klh6i5WHUqtKksqpkuZcUksq+T5mSSnK+V34o2LOc3s3qaxz5doQXzgoKGuGe.0GRLLX78fLgNj99pQRyRraJ3hQcONIpeHEZ88zSoYKTkmAssRQfFmFK49UOj5SIoYveR03VILsWrX9hq+ulPtwqODGCWac1n8+ceU5R+u9UouQd+0ahyHf3JEGmz6tlm9NFIfcyM+HekvM0isqfFDeMJV+vKT.Tg6XWWsK9SgBl4ulGt.q4QKvZd7BrlOaAVySVf074KvZ9h4tF8kKIsboS4.As1yzxgk0ndmAlN5eLgWzyA

This is a simple overdrive going into a 16x oversample node. With the new SuspendOnSilence flag enabled, the CPU usage goes down to literally 0% if there is no signal present. You can try to disable the flag to check the effect (it's in the DspNetwork properties, next to the AllowCompilation and HasTail properties. The flag will be passed to the node compilation, so the HardcodedFX will inherit the behaviour of the network.

Be aware that this flag should not be used if your algorithm produces any sound from silence (eg. a test tone generator or a background noise player), because it will obviously mute the output when the input is silent.

You can also see the suspend state in the Module Tree, if a FX is suspended, it will show a S over the peak meters like this:

I've tested it rather thorougly and tried to cater in all use cases (polyphonic FX will also be suspended if the voice is not producing any sound), but please let me know if you find any issues.

There's also a preprocessor macro in the hi_dsp module (HISE_SUSPENSION_TAIL_MS) which defines the time that the processing stays active after the first silence detection (the silence detection is pretty sensitive, so it looks for a -90dB threshhold), if you prefer a different default value, let me know.

In my project it yields a ~40% CPU improvement in idle mode and ~10% CPU improvement when in usage (because some channels of the plugin are not always busy). I also improved the performance of reading the peak values of routing matrixes, so this might also be a contributing factor though...

Hi everybody,

I'm very thrilled to announce that the Faust integration is merged into the develop branch and ready to test.

The implementation of the Faust integration was a Google Summer of Code project that I was mentoring together with Stéphane Letz, @sletz from the GRAME Research Lab. The project was carried out by @etXzat which I would like to introduce with a warm welcome and I'm sure he's happy to answer some questions about the process or anything Faust related as he knows much more about the actual language than I do.

The Faust language allows you to write DSP algorithms using a very concise language. It's been around for quite some time and has a lively community of developers and a vast library of existing DSP algorithms that I know all of you are dying to play around with.

The current state of the Faust integration allows the full production cycle of using Faust within a HISE project:

• add the core.faust node
• write / import Faust code using the LLVM Jit compiler. Parameters will be parsed automatically and show up as node parameters that can be connected / modulated like any other parameter
• export faust code as C++ nodes (a DSP network with a faust node will create a C++ class from the faust node and use the C++ class instead when you export the network to the DLL)
• reload them as HardcodedFX modules or nodes in scriptnode

@etXzat has written a extensive blog post about the integration process as well as the build instructions and a quick getting started guide:

https://resonant-bytes.de/blog/gsoc-final-submission/

By default Faust is disabled in HISE because it requires a few non-trivial configuration steps and let's be honest, HISE isn't the most easiest software to get started with so there's no need to make it even harder...

So if you want to dive into Faust development in HISE, make sure to read the build instructions on the blog post and let us know if there are any roadblocks (we've been testing it on all three platforms the last week but I wouldn't be too surprised if we missed some build issues).

Also we would like to start the discussion on what steps should be next as there are quite a few features that we couldn't realize within the projects timeframe but hopefully will be added over the next months:

• support for MIDI and polyphony (at the moment it's only possible to use Faust for audio effects)
• enhanced IDE features (editing within HISE, SVG path diagram preview, etc).
• support for complex data communication (tables / slider packs / audio files in Faust)

I've also added a new category in the HISE forum for anything faust related, so that this topic will not explode with all kinds of different questions.

After what might be the single most offensive violation of the git flow branching model in the history of software development, I finally found the motivation to merge the develop branch back into the master branch, which had a pre-pandemic state.

Also from now on, I vow to respect the traditions of software development:

• keep the master branch stable and build at all times so it can be a valid entry point for HISE newbies.
• use the develop branch for testing new features / daily development work.
• whenever I merge the develop branch into the master branch, I'll run a CI test that ensures that it builds HISE and exports a test project on macOS / windows so that @ulrik can stop being my human build bot for macOS and notify my that I broke macOS again... I will also try to bump the version numbers with each merge to master.

I'll expect the frequency of master releases to be a few weeks to months so the general advice that David healey gave in all videos since 2019 to use the develop branch for actual development stays valid.

Oh and I've thrown in VS2022 support so you don't need to crawl the web for an ancient version of 2017 anymore...

So time went on and I simplified the build process for Faust a bit so I thought I'll post the build instructions (or the link to the instructions) here and update the post once it changes:

Windows

No Projucer modifications necessary!

• Download and install Faust to the default path (C:\Program Files\Faust). The latest version is available here: https://github.com/grame-cncm/faust/releases
• Open projects/standalone/HISE Standalone.jucer and click on Save and Open in IDE
• Change the build configuration in Visual Studio to either Debug with Faust or Release with Faust. This can be done with a drop down menu in the toolbar (which initially says Debug).
• Compile this configuration. HISE will have a text label in the top bar indicating that Faust is enabled.

macOS

See here: https://github.com/christophhart/HISE/tree/develop/tools/faust

Linux

See here:
https://resonant-bytes.de/blog/gsoc-final-submission/

Then you just need to add the directory of the Faust installation to your HISE settings under FaustPath so that it can find the Faust libraries and you're good to go.

I'll lock this topic and pin it to the top now.

What's the best way to return to coding after a vacation break? Yes, adding a fun feature that is easy on the brain cells. So here I present to you:

Code snippet templates

These extend the autocomplete items with templates of commonly used code snippets. Check out how it creates a CSS definition for a button LAF within seconds:

These are the features:

• use the stock templates that come with HISE or add your own templates in a JSON file for the ultimate customization
• use the preselect range feature to create multiple selections after inserting the template

Docs:

https://docs.hise.audio/glossary/code_snippets.html

Have fun! Also I'm happy to accept snippets to be added to the default list, so post them if you find them useful!

Alright guys, here we go:

https://github.com/christophhart/HISE/commit/888851ed2353eec4684cd94ea0d5db5d2dae84ff

I tried to cover a few common edge cases, but I'm sure there's lots to discover when doing monkey testing, so let me know if you find glitches...

And on a tagent slightly, but one of the biggest hurdles to writing complex projects in HISE is just how many languages and approaches you need to take command of. In C++ I can focus on JUCE and C++. In HISE, I need to learn HISEscript, C++, SNEX, simple markdown, and even css. This is a barrier to speed.

Yup, I understand that, however nobody forces you to use CSS or markdown :) On the other hand, the LLM has no problem using different languages (assuming that I solve the knowledge gap problem to HiseScript and make the CSS parser a bit more standard conform), so I would say that if you don't understand CSS you can still use it through an LLM.

That's where it's been most obviously unusable for me; if I'm spending half the time reiterating the same basic Hise scripting errors back to the LLM, that's too much time and tokens wasted to achieve anything substantial. It's mostly the frustration of it that kills the motivation to continue, otherwise it has great potential!

Yes that is basically LLM integration 101: remove the friction point that it mixes up HiseScript and Javascript. I'm pretty confident that I'm 80% there with the MCP server and the latest models, but this will be an iterative process that will take some time.

But I agree that if HiseScript turns out to be a burden (hallucinates Javascript) instead of a opportunity (allow a fast & tight feedback loop) for LLMs then there will be smoother workflows from competitors, so this is a key problem for me to solve.

@David-Healey Yes I also tried Big Pickle, it has nothing to do with what Opus 4.5 / 4.6 can crank out. I'll try to remember a few of the things that stood out to me in my progress of last week.

• oneshotting a HTTP RestServer for HISE that accepts HTTP requests with a correct threading model.
• finding a bug in a compiled network code that caused a voice to not be killed. It explored it's way through the DLL boundary to the internal class that handles modulation chains and found the one bool flag that I forgot to set
• iteratively increasing the robustness and approximation to what looks like flawless HiseScript code by feeding the conversation history back to itself and just tell it to "learn from your mistakes"
• don't get me started on web dev, it's game over there.
• let it crawl through the HISE source code, extract every single LAF method I define in the ScriptLAF class, analyse the function body, connect it to the correct hise component class (eg. "drawAhdsrGraph" will most likely affect a hise::AhdsrGraph) and write a one-liner description to every obj property that matches exactly what it does, then create a JSON object that I can use for the MCP server. Then let it write a guideline.md file that instructs it to repeat that process whenever I need. Bash script on steroids.
• paste in long weird template compiler errors and get a 5 word sentence back what the problem is and how to solve it. It also wrote this beauty of a C++ template code that a human will never understand, but it works perfectly:

struct VoiceSetter : container::Helpers::sub_tuple<renderer<Oscillators, NumOutputs>...>
	{
		using GainModVS = typename core::extra_mod<NumVoices>::VoiceSetter;
		using GateVS = typename envelope::extra_mod_gate<NumVoices>::VoiceSetter;
		// Use empty tuple when addModToOutputs() is false, otherwise tuple of NumOutputs VoiceSetters
		using GainModTuple = std::conditional_t<addModToOutputs(),
			template_helpers::repeat_tuple_t<GainModVS, NumOutputs>,
			std::tuple<>>;
		using GateTuple = std::conditional_t<addModToOutputs(),
			template_helpers::repeat_tuple_t<GateVS, NumOutputs>,
			std::tuple<>>;
		// Delegating constructor for when we have outputs to manage
		template <size_t... Is>
		VoiceSetter(render_group& t, bool forceAll, std::index_sequence<Is...>) :
			container::Helpers::sub_tuple<renderer<Oscillators, NumOutputs>...>(t.oscillators, forceAll),
			gainModSetters{ GainModVS(t.outputGainMods[Is], forceAll)... },
			gateSetters{ GateVS(t.outputGates[Is], forceAll)... }
		{}
		// Delegating constructor for when we have no outputs to manage
		VoiceSetter(render_group& t, bool forceAll, std::index_sequence<>) :
			container::Helpers::sub_tuple<renderer<Oscillators, NumOutputs>...>(t.oscillators, forceAll),
			gainModSetters{},
			gateSetters{}
		{}
		// Public constructor - dispatches to appropriate delegating constructor
		VoiceSetter(render_group& t, bool forceAll) :
			VoiceSetter(t, forceAll,
				std::conditional_t<addModToOutputs(),
				std::make_index_sequence<NumOutputs>,
				std::index_sequence<>>{})
		{
		}

		GainModTuple gainModSetters;
		GateTuple gateSetters;
	};

compared to the complexity of these tasks, even a mid-tier HISE project should be trivial to implement as soon as the knowledge gap between C++ and HiseScript is solved (and that's my task now).

@David-Healey I don't want to be condescending, but have you tried using an AI agent with the latest models? Not like the local LLMs that you can run on your GPU and not one-shotting generic prompts into a ChatGPT window? You literally sound like me 2 weeks ago and I would have agreed 100% with you then and 0% with you now :)

I see a lot more threads popping up asking me to fix AI slop

Look it at this way: you're just one part of a very slow and ineffective Ralph loop.

@HISEnberg sure I'm holding back about 50-60 commits with that stuff, but as soon as the MVP is solid I'll let you all play with this. The current feature I'm toying around with is the ability to create a list of semantic events that will create a automated mouse interaction:

{
  { type: "click", id: "Button1", delay: 0 }
  { type: "drag", id: "Knob1", delta: [50, 60] , delay: 500 },
  { type: "screenshot", crop: "Knob1" }
}

AI agents sends this list to HISE, HISE opens a new window with an interface, simulates the mouse interaction that clicks on button1 ( had to hack the low-level mouse handling in JUCE to simulate a real input device for that), then drags knob1 and makes a screenshot. Evaluates that the expected screenshot uses the code path of the LAF it has send to HISE previously, then realizes that the path bounds need to be scaled differently and retries it until the screenshot matches its expected outcome. If it just needs to know whether the knob drag updated the reverb parameter, it fetches the module list from HISE and looks at the SimpleReverb's attribute directly - this won't waste context window space for the image analysis.

It's that feedback loop that allows it to autonomously iterate to the "correct" solution (aka ralph loop), so even if it only gets it 90% of the time right, it will approximate to 99.9% after three rounds of this.

@dannytaurus lol I burned through the 100 bucks Claude Max subscription in 3 days.

local is still here to stay, obviously otherwise every single script in HISE would break, so you can still emphasise this distinction if you think it adds value to the semantics of a script when teaching human noobs. The LLMs don't need that guidance though :)

The XML/node structure of HISE is ripe for AI collaboration I believe.

Actually, the XML structure is not the best target for this as this is a stale file that doesn't reflect the actual state in the HISE instance. The MCP server can query the entire component tree and fetch the properties, so you can select (!) some buttons in HISE just tell him:

"Move the button row to the top"

The agent will then call hise_runtime_get_selected_components, which returns a list of JSON objects for each selected component (like the actual selection (!) you did in the interface designer), apply the modification and send it back using hise_runtime_set_component_properties. then call hise_runtime_get_component_properties to fetch the current state again and verify it against it's expected position. This is a trivial example and the verification loop is unnecessary here, but you can imagine how that scales up to be a real workflow boost.

Hidden from view and resolved internally in the parser:

inline function dudel()
{
    // valid code now:
    var iAmSoSorryDave = "Why did I need to explain this to users for 5 years"?;
}

local alsoValid = "allTheTimeSpentExplainingThis...";

There's literally no field in the 2x2 matrix of valid input vs. scenarios that has more than one valid syntax so all this did was to make it complicated for both LLM and new user.

Type	Inline / callback	function / root
local	Works	compile error
var	compile error	Works

@HISEnberg I need to watch out that I don't start like my LLM responding to my input, but "Excellent feedback!" :)

All LLMs are not great with HISEscript still.

The knowledge gap between HiseScript and any other programming language is a temporary one. Sure only the big models somehow are fed with HiseScript and can one-shot you scripts that are (mostly) correct without any guidance, but that is precisely the pre-agent state of the art that I assumed will guard us from the robots taking over.

I think I need to catch you guys a bit up with what I did last week so that you can fully understand the fundamental change this will bring: the key to solving the hallucination problem (again, which I thought is deeply embedded in the very nature of LLMs) is to ensure that the context window of the LLM contains either the full set of API methods, language paradigms and properties (wasteful), or instruct the LLM to always query an existing set of resources before writing a single line of code.

There are multiple ways to achieve that efficiently and I came up with writing a custom MCP server that the agent can query and fetch the correct API method names & signature as well as component properties, LAF obj properties. including description. Then a reference guideline just needs to say: "WHENEVER YOU WRITE LAF CODE, LOOK UP THE FUNCTION NAME AND PROPERTIES!!!!!", give it the source and the LLM will lazily pull whatever it needs into the context window.

https://github.com/christoph-hart/hise_mcp_server

This provides the LLM with the always up to date (because automatically extracted from the source code) property list in a JSON format, eg. here for the LAF properties:

https://github.com/christoph-hart/hise_mcp_server/blob/master/data/laf_style_guide.json

Then whenever the user prompts something blablabla with LAF, it will pull in this style guide:

https://github.com/christoph-hart/hise_mcp_server/blob/2c37d5046414667d8f5229a5e2d3ece529225308/src/style-guides.ts#L114

read it and understand what it can call.

Running Claude Code, editing your scripts in an external IDE while recompiling in HISE is convulted.

The MCP server can talk to HISE via a Rest API and send recompile messages, then get the output back as HTTP response and change the code until it compiles. This is the core development loop that powers that entire thing:

https://awesomeclaude.ai/ralph-wiggum

@David-Healey luckily we can leverage that an AI agent and HISE newcomers have kind of the same knowledge point so improving the robustness of the LLM output will also remove friction points for human developers.

Just one example: I was testing some agent guidelines with a very small model to ensure that it gets basic tasks right. It always got local vs. var wrong so instead of me updating the guidelines to scream at the LLM to do this correctly I just realized that there is no scenario where you actuallyhave to choose between local and var. it‘s basically one or the other, so I just removed that entirely so if you define a var statement in an inline function the parser just silently converts it to local.

That increased the chances of a small LLM oneshotting prompts to about 80% and will also remove the friction point for new developers.