@HISEnberg haha yes that is some funky stuff, my favorite part is how I replicated the module tree in ASCII art:

I've also pulled in the entire setup.hise.dev stuff into this app - this bypasses some of the quirks of the website approach - now people just have to download this self-contained binary TUI app and type in /setup and it will perform all the steps from the setup workflow.

It also acts as logger for monitoring what the LLM does - if you have the TUI open and the LLM calls

hise-cli -builder add Sampler

then this shows up in the chat history with an "LLM" tag.

I'm probably moving all the runtime functionality out of the MCP server as soon as the hise_cli is ready so the MCP becomes a read-only documentation / explorer tool that sits on the HISE doc server - currently it needs to be run locally so it can connect to the HISE Rest server, but since the Hise-cli is doing the same thing too it's easier to separate these tasks.

The MCP server also integrates with the new doc website and uses a small embedding model and a vector database for looking up docs & code examples - I evaluated different approaches, but that gives me the advantage of checking the quality of the MCP search.

Actually nevermind just looked again you can unlock each expansion with a serial key. It‘s currently once per expansion but either you can add a input field where you can paste multiple serials for each expansion or we add a meta serial system that unlocks multiple expansions at once.

@Lindon the idea is that the user doesn‘t activate any expansions - he just fetches an encoded list of registered expansions from the activation server but I haven‘t figured out a way of how the server gets that information as this would involve cross server communication which I deferred until there‘s an actual use case

@Lindon It's already in the C++ code and the activate server backend also supports expansions as product addition, but we haven't used it in a real project yet, so you can expect it to be a bit rough around the edges.

I would point to the completely rewritten docs that explain this all, but then you'll complain that the 127.0.0.1 link doesn't work...

@Lindon that‘s actually a feature that I‘m currently developing - you have a single license that is tied to a user and the activation server stores a list of registered expansions and only allows to load the ones which are registered to the users machine.

@Sampletekk you don't get a script reference to the convolution node directly - this would prevent the ability of compiling the scriptnode network later. You need to set the audio file slot in the convolution node to an external one (click the button next to the audio file in the node, then choose External audio file slot #0 or #1 or whatever).

Then you use getAudioSampleProcessor("ScriptFX") to fetch a reference to the scriptnode network and then call getAudioFile(0) to get a reference.

This translates 1:1 for when you compile the scriptnode to C++ and load it into a hardcoded FX module.

@Sampletekk sure, check the filters.convolution node - it's the same as the stock convolution reverb wrapped in a node.

@David-Healey bypass the broadcaster with a scoped statement?

@Lindon I‘m pretty sure you can load another full instrument expansion without going back to the vanilla state, and a common shared left tab is not the hardest thing to implement - just make sure that code is self contained then ship the script files to each instrument using the asset manager.

@Lindon nope won't work.

Use regular expansions, make a map of all features / articulations you want, then embed a metadata system where you load the files as JSON from each expansion, then adapt the UI to show what you need.

The Full expansion mode is used if you actually want to make a company wide sample playback engine that can be fed with any product, but you loose the ability of loading content from multiple expansion (=each full instrument expansion is a closed off container, you just gain the advantage of not supplying one binary per expansion).

@Lindon you cannot add executable hise script in standard expansions - these are limited to static resources only.

you have two options:

1. implement all logic that is required by all expansions in the base project, then just hook into it. the additional data can store JSON - this would be the config setting for which expansion needs which logic.
2. If that isn't enough flexibility you can always use the Full Instrument Expansion route - this is basically what Rhapsody is doing. You get a completely dynamic module tree / script interface, basically Kontakt Player tailored for Lindon and every expansion is a complete HISE project.

@David-Healey ah yes I‘ve hacked around in the juce code to allow artificial mouse clicks to give the robot the ability to use the plugin interface but I haven‘t ported this to JUCE8 yet.

@Bart FYI I'm working on a TUI app at the moment that allows you to remote control HISE and perform all kinds of actions - the same command set is also exposed as an CLI interface for the LLM to use (and you can use the TUI app as a "log viewer" to trace back what the LLM did).

This will include a feature complete builder mode with full undo support where you can add / remove modules and change parameters from the command line:

https://github.com/christoph-hart/hise-cli/issues/5

@Casmat nice. if you want you can post the hallucination bugs and I'll add them to the MCP servers in the DONT section - that's an iterative process but since I'm working mainly with the Claude models it might be overfitting to their behaviour.

I'm also inclined to change the scripting language to support more "JS-type" constructs granted that it doesn't affect backwards compatibility and is within the scope of HiseScript - that's the gold standard of removing friction points, a DONT section in the unified style guide is a band-aid.

But the first line of defense against hallucinations should be the LSP server - this is another binary that is integrated with your coding agent and is executed after every file edit. This doesn't recompile HISE (and you have to disable the "recompile on file load" function in HISE for this to work), but it "shadow parses" the edited file and returns a multi-error diagnostic log with all syntax errors or hallucinated methods. It doesn't do real runtime inspection, but it catches missing API methods as well as a few custom diagnostics.

RE: your initial feature request. Have you checked using the Viewport's multicolumn mode for preset browsers? this should be vastly more efficient and is suitable for displaying hundreds of preset items without performance issues. ScriptPanels are too heavyweight to be used for a single row in high numbers.

@boim98208 the circles are only hidden if you enable the complex group editor as they don‘t make sense anymore when it‘s enabled. If you don‘t use the complex groups then it should still be there.

@Orvillain yup viewport should consume the mousewheel events of a child component.

@Orvillain yes they were relicts of long before the set call and I just forgot they exist until the AI tried to use it and messed up the magic numbers. There‘s no need for it - they just route to the set call but without a self-contained explanation.

The content.setColour call sets the background color of the interface and can easily be replaced with a panel if a plan colour background is what you want.
Are you using these methods?

Nobody is expecting that AI will produce interesting plugins on its own - the same as it will never produce interesting music with any artistic value ever.

It‘s the middle layer that handles the transformation from a human having an idea and vision to a plugin that is completely being revolutionized at the moment - this is where HISE sits and ignoring this paradigm shift would be suicidal for a framework like HISE which is why I‘m pulling 14 hour days since about 3-4 weeks to figure out the best way going forward. The way Opus 4.6 interacts with the current toolset I‘m developing is uncanny though and goes far beyomd simple LAF stuff - it eg. oneshotted the transformation of a fairly complex user preset model to the custom automation handler then Ralphed it‘s way to find out that setting processorIds will make the control callback not fire - with proper guidance and planning, which ties back to daves distinction between vibecoding and AI assisted development.

But how and why did we get to the point of writing code using AI

Simple: the latest iterations of the SOTA models make AI coding on par with a reasonably well skilled developer.

@David-Healey that should be covered by that wildcard function, any file that matches against that wildcard would be excluded from the deinstallation procedure (and before installing it checks if it exists, then does nothing). A big XML file would be a bit tricky though - you can never change that template file because it would never be updated - with script files you can branch out your config stuff into a seperate smaller file.