@Christoph-Hart said in Is the HISE REST server ready for use?:

It's not intended to be used directly as REST API but the hise-cli app will talk to it and Claude should use the hise-cli app as this is more token efficient than dumping the entire HTTP response into the context window.

Makes sense. Using it through the CLI now 👍

Using REST directly was having things like the /repl endpoint not recompiling the scripts, and some values getting out of sync during saves.

But the CLI between seems much better now. Thanks! 🙌

@David-Healey That's where I use it (the blank part above it the bottom of my property editor)
But it's now back, I just needed to remove it and re-insert, probably a compromised window XML...

@Chazrox I thought I fixed it about 2 weeks ago. It was a line that was already there so I simply uncommented it and it was working nicely in Hise. But I suspected it made my plugin unstable/causing crash, so I just went back a step.

I'm not 100% sure it was the real cause, but since the line was commented, I think @Christoph-Hart had a good reason...

@David-Healey No, because this is about persisting the file to the user's disk.

Although as I said earlier, I think the final best answer is to display the license directly in the plugin somewhere.

Then nobody could ever accuse the developer of not making the license easily available.

Website goes down - no problem
User moves the plugin to another machine - no problem
User wipes/moves/modifies their AppData folder - no problem

If the license is in the plugin itself, it can't be accidentally moved, deleted or overwritten, and it can't become unavailable because of server outage.

Probably going this route now...

@Lindon Yup that's because it needs to be thought more as "container" rather than strictly "installer". PKG or ZIP are containers so -> notarisation

@Lindon Yes you spotted both of the main issues:

JuceHeader collision. Previous versions used #include "../Binaries/JuceLibraryCode/JuceHeader.h" which was fine for the DLL, but exporting to VST3/AU caused the JuceHeaders (project info like companyName, versionString, etc.) to be pulled in twice. Solution is just to use #include <JuceHeader>

.cpp.inc is resolved on all Fx to just .cpp (it was a leftover from the batch compile I ran).

A handful of effects couldn't be compiled together — some of the amp/saturation nodes (the ones based on a shared __Gain_H template) and a few of the k-reverbs. Individually they were fine, but combining them caused build errors. It came down to a couple of effects accidentally reusing the same internal names behind the scenes, so they stepped on each other once everything compiled together. That's now sorted out, and the full set compiles as one.

The repo is up-to-date now and should be more stable.

@David-Healey Looks great! I kid ye not, I'm noodling on my website redesign now and used very similar colours and layout!

Total coincidence! 😂

CleanShot 2026-06-18 at 19.05.42@2x.png

CleanShot 2026-06-18 at 19.05.32@2x.png

@ustk @griffinboy that def does so thank you so much.

P

@lijas90 Thanks!

4 over 4, that's enough stats for me 😎

I thought at one point the "full mod range representation" has been made available so it covers the full range of lastModValue (like in the above post)

Was I dreaming?

modvalue.gif

@David-Healey I added a dragThumbOnly property to Scriptslider

if enabled:

A left-click on the slider track no longer starts a drag or jumps the value.
HiSlider::mouseDown hit-tests the click against the drawn handle centre
and only forwards to Slider::mouseDown when the click lands on the
thumb (within dragThumbSize/2 + dragThumbPad). Right-clicks still pass
through for MIDI-learn / context menu. Snap-to-mouse is disabled, so dragging the thumb is relative and the
value does not snap to the cursor on click.

if anyone is interested it's on my fork
https://github.com/morphoice/HISE/commit/7b206d1951558381a2a38b2691a504d7542eec56

however the dimensions are currently hardcoded to my needs, so there will be further changes needed to make this a general feature. I therefor didn't make a PR

@David-Healey The Problem was that I was including the same Expansions.js in the actual Expansion! Ive commented that and deleted the file and is working in the exported Plugin!

@David-Healey Thank you, kind sir.

@Oli-Ullmann Ok,

Thank you 🙏

@paper_lung Gotcha. Not too far behind then. Still worth getting up to date though 👍

@VybeCodeDSP StripKit looks really nice!

It seems you only support the Windows platform?
If so, are you planning to support MacOS?
If so, let me know if you need a beta tester!

@paper_lung Check this thread: https://forum.hise.audio/topic/5499/audiowaveform-laf

@Sawatakashi said in Which version of faust works fine for HISE？:

it crashed after i loaded a faust scriptnode.

A blank node or are you copying in a script?

@dannytaurus Yeah, keeping the colours tidy in your code is easier in the end. Then you can set the component colours from script when needed and everything updates automatically if you adjust something instead of copy/paste in all components...

I tend to to everything I can in paint routines, the less components in the tree, the happier I am!
That being said... In order to reduce CPU load, I still tend to keep fixed drawing (bg, mask, etc...) in separate panels so the LAF function job is only constrained to what is really necessary. I also keep all the math constants externally, unlike the example...

Other issue with the "multiple panel masking technique" is that when you want to move it, it can be very annoying, unless adding them all in an holder panel, which is one more component... 😬