@Christoph-Hart said in HISE with Claude:

just fyi at this point the hise-cli contains the functionality of the mcp server and the lsp server so it's the all in one solution going forward.

so we'd just need to point Claude at the HISE-CLI then? (Asking for a friend)...

@Chazrox said in NEW GUI DESIGNER APP! ::: Rox Designer Suite::: is LIVE!:

@Lindon There are file-handling features that cant be done in a web-browser so Im switching to stand-alone.

..and the web version will remain "as is"?

@ustk thanks mate I will give it a go...I have no idea how to do a "correlation algorithm" but its all an adventure...

@ustk said in Measuring plugin delay times....:

@Lindon My process is to automate this from Hise itself.

You can write a test script that:

• loads the FXs one by one
• play a test signal
• record that test signal before and after the FX in 2 scriptFX module process callbacks (or 1 unique recorder with 2 passes, bypassed/unbypassed)
• perform a cross correlation between the two buffers to get the sample diff
• and populate an array that will hold the latencies per FX

Claude can easily create this for you if you need

And as @griffinboy said group delay can be tricky and give weird results, especially with impulses. I'd do it with white noise since cross-correlation is very effective with it (I do this in my Align-IT app)

do you have an example(snippet) of this cause I dont(yet) use Claude and its all new to me.

@Chazrox ok well this is getting a bit out of hand - I cant work out what Im getting, and its asking for a LOT of personal information....Im beginning to think this is a bad idea.

Okay, so I have a massive multi-fx plugin - there are 6 slots in it, and each slot can load any of the FX that ship with the plugin.

There are 133 FX.....

Yep, thats not a typo ... 133 FX.

Any of these can be loaded into one of 6 Hardcoded FX "slots", there are C++ FX, Scriptnode FX and Faust FX all in there....

So now I'd like my plugin to report to the DAW some consistent delay time...

So the plan is, nothing special here, to have a variable delay at the end of the chain....whos value can max out at the worst case scenario (6 copies of the worst "performing" FX loaded across all slots in the plugin), and to calculate every time a new FX is loaded what the current delay is - and add "make-up delay" to get us back to this worst case scenario - and thus always report this worst case to the DAW.

Now I realise that some of the actual delay any given FX induces may well be changable based on the params the FX are set at, the sample rate being used or even the type of content arriving at the plugin.... Im going to live with this inaccuracy.

Heres the plugin layout - its pretty simple:

So, to the question:
What currently the best way to measure delay induced by any given FX?

@Chazrox said in NEW GUI DESIGNER APP! ::: Rox Designer Suite::: is LIVE!:

FOUNDERS100

So Im confused now, whats happening with the web-bazed solutions?

@dannytaurus said in Latest version of HISE breaks existing presets....:

@Christoph-Hart Here's what 'my' Claude says:

The pattern so far

Since a92a701de (the unified automation base class), every automation actor - host parameter, macro, MIDI automation, UI widget, script, preset restore - is both a reader and a writer of shared values, connected through the dispatch library. The regressions since then have all been the same bug wearing different hats: a listener can't tell an echo of its own write from a real change, so it feeds the value back around the loop. Each fix so far suppresses one specific edge:

• 633626eeb - gate refreshParameterValue() on enablePluginParameterUpdate, and switch MIDI automation's setAttribute from async to sync notification
• e1fb54695 - carve the backend macro-to-parameter-slot routing out behind HISE_MACROS_ARE_PLUGIN_PARAMETERS

Alongside the pre-existing guards (recursive, sendToHost per parameter, deferNotifyHostFlag, the exclusive-mode conditionals in loadUserPresetInternal()), that's now seven or so overlapping mechanisms all answering the same question by inference: "is this change an echo?"

Why I think flags can't fully close this

Two structural limits:

1. The global flag suppresses the wrong scope. enablePluginParameterUpdate is one boolean for all parameters. While parameter A's update is dispatching (flag false), a legitimate concurrent change to parameter B hits the early return in refreshParameterValue() and is silently dropped -the internal value updates but the host never hears it. I suspect this is exactly the DAW-project-vs-internal-preset drift you were hypothesizing about at the end of the thread. The guard isn't just failing to fix that bug, it's a source of it.
2. Scoped guards can't survive deferred dispatch. A ScopedValueSetter protects a call stack, but this system defers across threads by design. By the time an async-queued listener runs, the guard is long restored and the echo sails through. That's why 633626eeb had to change MIDI automation to sync notification - to drag the callback inside the guard's scope. Changing threading semantics to make a boolean reachable feels like the approach hitting its ceiling.

Proposal: make provenance explicit

The class structure from the rewrite is good - I'd keep all of it. The change is to what a notification is: value plus origin, instead of value alone.

1. Add a small source token (Host, Macro, MidiAutomation, UI, Script, PresetRestore) to SlotSender::sendChangeMessage() and the listener callbacks, threaded through CustomAutomationData::call(). Because the token travels with the queued message, it survives deferral and thread hops - the thing no scoped flag can do.
2. Each writer passes its own token and ignores incoming messages carrying it. MacroPluginParameter::setValue() writes as Host and skips Host-tagged notifications; same pattern in HisePluginParameterBase, MidiControllerAutomationHandler, CustomAutomationParameter.
3. recursive, sendToHost and the global enablePluginParameterUpdate then become deletable. (deferNotifyHostFlag can stay - batching host notifications is an optimization, not a correctness guard.)
4. Preset restore becomes a first-class source: "macros must not clobber freshly restored widget values" becomes a one-line filter rule instead of an ordering convention plus exclusive-mode conditionals, and the MIDI sync/async choice stops mattering for correctness.

For precedent: JUCE's own ParameterAttachment solves the identical loop the same way - each attachment filters its own echoes at the attachment point.

Hmm, I must give this Claude malarky a bit of a go......

@Christoph-Hart yep, as soon as I can I will test it out, though I did send you a version of the project and I think the thread documents the problem well enough....

@Christoph-Hart - is there any chance of ever getting a fix for this?

@lijas90 your installer needs to create/write to the Link file in the %APPDATA% folder with the path to your samples. so on Windows this is LinkWindows, on MacOS its LinkOSX.

As an aside putting samples in the %APPDATA% folder system, as you are doing, is generally a bad idea, esp. for Windows users who often have small C; drives (where the %APPDATA folder resides) as thus there is not enough room for the sample set. Better to ask the end user where they want to keep their samples during the install.

@39oririn

go to :

https://github.com/christophhart/hise-cli

and follow the instructions there...

@David-Healey I was looking for a simple one-man-band way to get past the windows "smart screen" - but thanks anyway....

@David-Healey said in Why I'm not making a Windows installer (nor code-signing):

@dannytaurus The same certificate can be used for AAX on both macOS and Windows too.

Windows too? How?

@Yannrog said in Moonbase integration to Hise:

@David-Healey I definitely need an authentication for sure, do you know one ?

there are a number try soundSync

https://forum.hise.audio/topic/13559/soundsync-reseller-security-serial-management-platform

or Inlay

https://inlay.cloud/

or HISE activate

https://activate.hise.dev/

@Chazrox said in MAJOR UPDATE // NEW: Online KNOB BUILDER for HISE!! // Factory/User Preset System:

@Lindon Thank You!

@Lindon said in MAJOR UPDATE // NEW: Online KNOB BUILDER for HISE!! // Factory/User Preset System:

maybe you can

No you're right, I didnt add alpha sliders to the flat colour selections. I'll def add that in the next update. I appreciate the feedback.

Actually it was alpha applied to the gradient colours that I was after...

@Chazrox Ok so I've spent a little time with this now, well done its great. One thing I think would add to its utility is the ability to set the alpha value of colours, maybe you can but I cant see it...

@lalalandsynth said in Sneak Peak at my 'SLIDER BUILDER" app // Feature Requests anyone?:

@Lindon Why not ? Not all at the same time , just tabs to flip between knobs, buttons, sliders.

because you are throwing everything into one bucket when the problem you describe can be addressed by shared themes.

@lalalandsynth said in Sneak Peak at my 'SLIDER BUILDER" app // Feature Requests anyone?:

@Chazrox Should it maybe all be one app ? Easier to make matching assets , hex codes etc .

good grief no!