administrators group

Christoph Hart

@Lindon nah, that's ancient. @mehmethand have you recently updated faust and did it work before? And the standard process = _,_ stub - does this crash too?

Christoph Hart

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

Christoph Hart

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.

Christoph Hart

@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

Christoph Hart

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

Christoph Hart

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

Christoph Hart

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

Christoph Hart

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

Christoph Hart

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

Christoph Hart

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

administrators

Posts

Member List