I finally had a chance to dig into the new setup this week and my head is still spinning with the possibilities. I agree with Christoph that there is something almost uncanny about Opus 4.6 (I'd add Sonnet 4.6 which I use for most tasks) when it comes to writing Hisescript and editing the source code. Next best models which I find produce useful enough results are GPT-5.4, and Gemini's new multimodal embedding model has piqued my interest as well.

It's still early days of trying out different workflows but what does everyone's setup look like currently? Are you still using the HISE script editor or do you find working out of a separate IDE more convenient at this point? I've been using Visual Studio for the most part launching Claude Code or Codex in Terminal. Admittedly, I still find HISE script editor too useful to completely separate with it...

On another, note how are you all getting along with specific HISE projects at this stage? One thing I am noticing is how much more aggressive Claude code can be on token usage if you don't prompt and direct it right. Previously I would consolidate all necessary information (Scripts, xmls, Dsp Files, scope of work, bug checklist, etc.) along with specific examples, API documentation, or source code from HISE, and create a new project with an LLM. This seems to have the added benefit of keeping the model more focused, faster, use less resources, and most importantly, retain memory. The main drawbacks are lack of project/HISE context and lack of writing to project.

So the MCP server approach does allow for read/write to the project and clearly performs significantly better, but requires careful prompting and project context to avoid significant token usage. Figuring out the right balance between comprehensive context and efficiency is the real challenge for me moving forward. I imagine this just boils down to reformatting my setup to include the right sort of skill, tools and spawning subagents in the right context.

I'll have to try out opencode as Chrsitoph suggests and using this to make edits to the HISE source code are next on my bucket list as well!

@Jeetender Check the docs. Looks like you're missing an 's' at the end - setForwardControlsToParameters

https://docs.hise.dev/scripting/scripting-api/dspnetwork/index.html#setforwardcontrolstoparameters

@Jeetender use an RMS calculation.

@jenö What changes have you made to the juicer file?

@ustk

Thank you, that worked! I needed to delete the contents of the HISE Application Support folder.

@David-Healey said in Exporting plugin with expansions?:

@filipalex96 said in Exporting plugin with expansions?:

The actual samples used by those samplemaps are in the MAIN Samples folder

The expansion's samples should be in the expansion's folder.

Well..... not the way I do it....you can put the samples in the Linkfile directory - where all your factory samples are, so in your sample map it just looks sorta normal e.g.

FileName="{PROJECT_FOLDER}fatty_F#4.wav"

Essentially the sample map tells HISE where the sample data is by using this {PROJECT_FOLDER} token, which means "the folder wherever the end user decided to keep the samples, who's location can be found in the Link file"

You just need to tell your sampler where the sample maps are.... it already knows about your factory sample maps - they are shipped in the plugin, so you just need to tell it where each expansions maps are...

So you will need some meta data to differentiate your "factory" maps from each of your expansion maps, so my factory meta data for this location looks like this:

{ "VoiceMapName": "FireBreak" } note theres no actual location data in here, HISE, and your product already know about this map so none is needed.

whilst my expansion meta data looks like this, for an expansion called AlarmSemaphores:

{ "VoiceMapName": "{EXP::AlarmSemaphores}AS_Absentees" }

OK so another of these token things.. this time {EXP::expansion folder name}, which tells HISE, and your product to go look in the expansions folder for a sub folder called AlarmSemaphores, and there to look in the SampleMaps folder

So at this point you only need to set the expansion type to FilesOnly and have a way to place each expansions folder structure, which is entirely empty except for the sampleMaps folder which holds all the sample maps for your expansion.

So your Expansion installer will need to:

copy the sample data (.ch1 files) to the Linkfolder

Create a folder structure in the products Expansion folder
Here's an example:
c05bee1c-3a62-45af-be64-e770c392ae99-image.png

Inside each expansion folder create the std expansion folder structure:
6cf9a22c-a4ba-4744-bfdd-634d0a309ec4-image.png

inside the SampleMaps folder add the sample maps:

34e59a36-b8f8-4049-940d-1a2c2f3e392f-image.png

Create some meta data file that describes these maps and where they are so your product can find them...

If all of this is "too hard" then once the Asset Manager is up and running I will add a (for fee) version of this system so getting up and running should be pretty painless...I've been using it on HoriZEN, and now Atmosia 3 for over a year and it seems to work fine.

@Jeetender This issue comes up every now and again, check here.

Following from Dan's suggestion I had Claude take a look and it extended String.fromCharCode to support hex strings in addition to integers. This has solved the issue.

PR

@David-Healey Aha, that's great! I'll go study right away!

🔔 KNOB WEB STUDIO 11 – New Update https://www.knobwebstudio.com

Major update, discover ! 🤙🏻

Capture d’écran 11-03-2026 18.19.01.png

@l4ch standalone doesn’t provide audio inputs. That been said I have made a fork with audio inputs, but I still have some issues when exporting a standalone app on windows (the driver selection freezes the app) but it’s working on mac. If you export a plugin though there should be no issues.

Another warning is that the audio inputs are directly sent to the output, creating a dangerous feedback if you have a microphone connected and speakers on ! This has to be kept in mind during development

I’ll try to make this fork available soon when I’m back (not today)

If you can use the plugin version of Hise, there’s a multichannel projucer project already available

haha actually that was one of the few lines of code that I wrote myself - I was testing out some new logic that catches deprecations but somehow I deleted that line.

Funnily the documentation pipeline that I'm currently running over the entire codebase to recreate the API docs flagged this as an issue:

Missing registration: drawFittedText has a wrapper (API_VOID_METHOD_WRAPPER_5) and full implementation but does NOT appear in the constructor's ADD_API_METHOD calls. It is present in the base JSON, meaning the Doxygen-based generator picks it up from the header declaration. Whether it is actually accessible at runtime is uncertain -- it may be silently unavailable if the ADD_API_METHOD is required for the scripting engine to find the method.

But it then got lost in the noise - I have a system that populates a list of bugs / small issues that the doc generator discovers while chewing through the code, but here it didn't appear too:

https://github.com/christoph-hart/hise_api_generator/blob/main/enrichment/issues.md

@David-Healey Killin it.

@David-Healey Most of those errors were just stale files that a make clean didn't get rid of, I needed to remove the build folder completely.

The error relating to DELETE is caused by one of the include files on Linux systems declaring a DELETE macro and this conflicts with your enum.

A very minimal PR to unset the macro seems to solve it.

@l4ch Yeah I try to keep it up to date. I think I'll be updating it again when the setup.hise.dev script is fully tested and has all the features across all platforms.

Seems like the issue was the high-shelf node.
The plugin functions fine without, but doesn't seem like a solution for the future to just not use it at all.

@Christoph-Hart Understood, thank you.

@David-Healey Thanks!