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.

Hi everybody,

this might be my longest post in the entire history of this forum, but drastic times require drastic measures. So...

The last two weeks I've been reevaluating the newest progress in AI technology and testing the "new" (lol, welcome to the future) workflow of agentic coding. I was burned in the past with getting duped by AI hype stuff where it failed even the slightest complexity increase from a hello world toy request, so I thought this would be just another case of AI bros trying to collect the next round of venture capital to keep the servers running.

Well, here that's not the case (happy to explain why if anyone's interested) and the implication this will have on software development in general and the future of HISE in particular are completely transformative. So first of all I want to apologize to all the people here in the forum (notably @dannytaurus and @clevername27) which tried to point me to agentic coding which I've dismissed as AI slop (again: burned before).

Now I've spend the last week evaluating this in different use cases:

• scripting in HISE
• codereviewing complex HISE projects
• web design vibecoding funk
• deep architecture redesign in C++
• feature changes in C++
• bug fixing & debugging in C++
• new feature development in C++
• documentation building

to get a in-depth look into what the current state of the art models excel in and where they still need human guidance and knowledge. So the good news first: I'm pretty confident that we will still need developers for the foreseeable future that guide the AI to implement projects (so your job is safe), but the way that we will achieve this goal of "writing" software will never be the same again (so mine is not). If I could press a button and make the entire AI thing and its implications it has on society, politics and ecology disappear, I would not skip a heartbeat and smash that button like the subscribe button to David Healeys Youtube channel, but it's out in the world and it will stay, so it's adapt or die. One probable outcome of this is that the black magic art of plugin development will be democratized to a point that will completely devalue mediocre work in that field, but this is nothing that we can impact in any way.

So the fact that the way we write software going forward has changed forever, it obviously has severe implication on the entire relevance of the HISE framework. From its days of just David and me in this forum until today, HISE acted as a bridge to enable people to implement their audio plugin projects without knowing C++. That nice USP is gone out of the window and it's inevitable that there will be alternative tools that achieve that same goal. While the current projects that are popping up which lets you vibecode a plugin (see the iPlug3 thread) are far from being a full competitor to what a experienced HISE developer can create with the HISE framework, it would be a super ignorant thing to just ignore all that and keep HISE on the "pre-agentic AI" course where we explain new developers what the diffference between local and var is.

I'm currently reviewing the entire feature scope of HISE and its user flow / benefits that it provides to developers in order to evaluate which parts will be completely irrelevant going forward and which parts will bring additional benefits to the Agentic AI workflow that might ensure the relevance of the framework in this new era. My current assessment (which might change over the next days / weeks) is that having a mature codebase (and community!) like HISE that gives you the guardrails of a structured project layout, high-level modules and a tight feedback loop for the agent to iterate fast might be enough to justify its existence and make it a viable option as a framework in the next years to come. Obviously I'm totally biased at the moment, because the alternative is just rolling over and give up.

In this phase of my assessment I'll try to be as open as possible and also would like to start a discussion about this entire topic as I'm really curious about your feedback on this matter. So currently Dominik and I are working on these things in parallel (because they heavily influence each other):

Documentation Redesign

We'll be doing a full redesign of the docs. My initial experiences of letting the latest coding models explore the HISE codebase and come up with factually correct and comprehensive documentation just by looking at the source code is one of the most mindblowing experiences I had so far - if you have a few tokens left on your Claude account let it explore the HISE codebase and explain everything related to eg. ExternalData to you. This is an easy win where everybody will benefit from even if we wake up in three months and all that AI thing is a fever dream of the past because the VC capital dried up and nobody will pay 9000USD/month for a Claude Max subscription to cover the actual costs. We'll structure the documentation redesign with both AI agents and human readers in mind, but with the realistic assumption that there will not too many people reading docs in a few months. I think going forward having a non-complete / deprecated and clunky documentation like the HISE docs are right now is completely unacceptable - one could argue that it was unacceptable in the past too, but here at HISE we don't care about the past, we care about the future.

AI Agent Hackathon

I'm toying around with AI agents and how to integrate HISE into a agentic coding workflow. I can imagine that having a fast and tight development loop where the agent can compile scripts, evaluate the outcome and test it will bring a significant advantage over the current agentic AI workflow where you have to compile C++ and load a plugin, then test it. If this assumption is true, then HISE will have a significant head start and we all can happily ride into the sunset together. The "gold standard" for this is web development and the toolchain that a browser gives the AI: once you've watched it one-shot a next.js webserver application and debug it live, it's pretty jarring. In this scenario, HISE would be running next to the coding client but you would spend most of the time instructing the client and just interact with HISE to play around with it or occasionally inspect some script / debug it. So having a working version of your project available to test / inspect and analyse will still be valuable, but I can imagine that the actual UI of HISE (as in the window you're looking right now if you open HISE) will drastically change to accomodate to that workflow. Note that I'm a super noob when it comes to agentic coding so I'm happy to discuss your insights you gained when doing agentic coding regarding context window management, general best practices and all that. This is really a completely new skill to acquire as a software developer so let's do this together - most resources you can find are for web-developers and if I watch another video where a web developer shows me how to implement a shopping cart with a detailed todo planning list I'll puke, so being able to discuss things related to AI audio software development will be very important.

Transform the HISE codebase

There is a slight chance that the combination of my coding style which I would summarize as:

• thinking very long about architectural design of the framework to ensure its robust
• be super critical about performance relevant parts of the codebase
• then crank out undocumented code that only I understand
• half ass the UI to be a non-intuitive grey mess

is a match made in heaven with the "skills" that AI coding brings to the table:

• completing what I've started before my brain moved onto the next shiny thing. Eg. getting that CSS parser from 80% standard compliancy and bug-filled entry points (missing ID selectors, etc) to 99% compliancy should be a 1-2 day job.
• do the footwork of writing proper unit tests and code documentation, then do code reviews to spot any typos I made.
• design a UI that people can use intuitively
• fix regressions and analyse the codebase for gunk and duplicated stuff that I don't use myself daily and thus don't get the attention it deserves (eg. the entire sampler workflow)

So if the stars align, this will bring a code quality / usability boost to the HISE codebase in the next months that should give it enough headstart to be one of the front-runners in the new age.

Future-proof the framework

What parts of HISE are deprecated (spoiler alert: probably the code editor) and where to focus the attention on. Here I'm heavily relying on your feedback because this will lead to decisions that will change the way you will work with HISE so I wouldn't want to do this before discussing things thoroughly. I'm currently in the acceptance stage of grief for most of my darling features in HISE, but I'm also looking forward to remove large weird chunks of the codebase (like the entire markdown doc generator system, such an abomination of a doc system lol).

Anyways, let me know what you think the impact this will have on you as a HISE (?) developer. There will definitely lots of tribal knowledge that you've acquired over the years working with HISE which will get irrelevant pretty soon, but what would you expect from a framework like HISE in the new age? What would you say would the core-skills be that should be part of the toolkit of anyone working with HISE?

You can see that I've made a new category in this forum "AI Discussion" which this is the sticky starter thread alongside a few other posts that I tried to sort so that the different discussions don't end up in one big fat post, so feel free to start any conversation about this topic in there:

https://forum.hise.audio/topic/14391/agentic-coding-workflows
https://forum.hise.audio/topic/14392/hise-transformation-to-the-new-age

TLDR: just tried claude code, we're all fucked lol.

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!

Don't use it, it's bad and will be gone very soon.

yeah, the attempt of wrapping up the mod matrix lead to 5 people having 20 different requests for their individual projects. Maybe we need to settle on a common denominator feature set and make this robust - that's what this system was designed for.

@DanH you‘re using an outdated projucer build - it can‘t parse the vs2026 config. Make sure you use the latest one from the repo

this function is only available for a Table, not for a ScriptTable.

yes HISE, good HISE.

@David-Healey I don't think it's a regression, if it happens to CUBE then it has always happened - I'm fairly confident they are not using the latest HISE version for their current version.

@HISEnberg ah ok and it‘s still happening on the current dev branch? The cube plugin is quite old so it might be fixed in the meantime.

@Straticah Can you try to make a minimal example that crashes FL Studio? You can start with the webview examples in the hise_tutorial.

Ripping out the webview for your preset browser would be the wrong move, let's see if we can fix that.

@DanH raw output from the broadcaster wizard works:

// Broadcaster definition
const var asd = Engine.createBroadcaster({
  "id": "asd",
  "args": ["processor", "index", "value"],
  "tags": []
});

// attach to event Type
asd.attachToComplexData("Table.Content", ["LFO Modulator1"], "0", "");

// attach first listener
asd.addListener(0, "set content", function(processor, index, value){
	Console.print(value);
});

@Oli-Ullmann weird looks like a regression and it only happens if you replay the same note. I‘ll take a look later.

I'm pretty sure HISE has shown up at some point on Audioz.net with a rapidshare download link. Fun times back then, no looming AI apocalypse, just good ol' copyright theft by script kiddies.