@ustk said in [Blog] My Favourite C++ Open Source DSP References:

@Orvillain Yes that was my first attempt at making a nice reverb too and I learned a lot fro Geraint! I did it first with a network so the efficiency was bad but I've added some really fun stuff to it! But next time I'll obviously go C++...

It's probably a conversational side-quest, but I've stopped using scriptnode tbh, other than for wrapping my custom nodes and attaching parameters so the UI can access them. I don't like the workflow at all really.

@Morphoice said in ALT+S requires TWO confirmations. Can this be switched off?:

I'm pretty sure you all know hitting ALT+S...

Not really and I've found nothing general about this, more app specific stuff... Please enlighten me 😺

I'm looking for documents and examples to guide you and I am seeing this is rather poorly documented.

Basically DspNetworks folder works like this:

DspNetworks/Binaries: The compiled DLL. When you compile networks to .dll, HISE is launching and creating a mini-project of just your FX networks, so it contains a .jucer, XCode or VisualStudio file, etc. DLL (Dynamic Link Library) is, to put it crudely, a pre-written and formatted library that contains the DSP code which HISE can load at runtime (for example, load into the HardcodedMasterFx). You can simply delete the entire Binaries folder before compile to DLL for a fresh start (in fact it is a good idea). More info here: https://docs.hise.dev/scriptnode/manual/third_party.html

DspNetworks/CodeLibrary: I don't look here much, but it's usually where a lot of the faust and snex networks are saved to.

DspNetworks/Networks: Where scriptnode networks are saved as .xml. So you can actually look at these in a code editor and see the same structure flow and module settings (it is fairly human readable). This is what is saved and recalled when you are launching networks (it's very similar to how a User Preset works).

DspNetworks/ThirdParty: Mainly for C++ files if you are working that way. I think Snex headers are stashed here as well (I can't remember). You'll also notice HISE will autogenerate headers depending on what you are using, example for Faust.

AdditionalSourceCode/nodes: This is also important. When you go to compile networks you see the menu below. Basically it is autogenerating some headers that are stashed here for when you are ready to compile the entire project. They help link the compiler to the necessary DSP files. You don't really ever need to bother with this folder, but for a completely fresh build, you can just delete the "nodes" folder before compiling the networks to DLL.

Screenshot 2026-06-04 at 6.58.44 AM.png

@Lindon

Yeah thats another way to do it!
Basically the same idea.

Except like you noted, the Hise filters (which I think are ports of the stock Juce ones?) are primitive, they cramp in the high end of the spectrum (the filter shape get warped near nyquist). And so that's not very nice to see on the graphs.

Plus, the trouble with analog style filters (if they are actually simulating the hardware topology) is that the cutoff frequency on the knob won't actually line up with the frequency in the real filter, the cutoff frequency on the graph won't really match the real frequency the filter is at internally.

Thanks guys much appreciated

@observantsound said in Usinge the same sample files in two different sampler links them when editing.:

Is this a known bug?

It's by design.

@observantsound It's probably something to do with how the stretching algorithm works. I also noticed your sample is 44.1kHz, 48 might produce better results.

@David-Healey Of course! Silly me.....

@David-Healey so there's no way my server could be faster, especially since it is actually very slow...

@David-Healey yeah that seems more comprehensive, its more or less doing under the hood what Im doing in HISEScript... so both approaches have the advantage of getting a result back for the plugin itself (no matter how the user has set up to run it..)

Thanks for looking and confirming what I'd found.

@dannytaurus It working soo fine, I had to put engine.loadaudiofilesintopool earlier

@ustk Thanks for your hard work!

@Orvillain ill give that a try thanks. I don't have claude code though. I cant afford paid services at the moment

Very cool man!

@David-Healey It was already default to 500 mb in 4.1

It depends whether you want it to be a static connection or a dynamic modulation routing.

If static, then a control.pma node would be the best candidate - connect the UI knob to the value and the envelope output (either from an extra_mod or an inbuilt scriptnode AHDSR) to the add output, this will combine the two with unipolar modulation mode.

Scales and offsets a normalised modulation signal using a multiply-add formula with clamped output.
The PMA node (Parameter Multiply Add) scales and offsets a normalised modulation signal. It takes a 0-1 input value, multiplies it by a configurable factor, adds a constant offset, and clamps the result to the 0-1 range. This is one of the most commonly used control nodes for adjusting modulation depth, inverting signals, or combining parameters.

Each parameter change triggers an independent output update. If Value, Multiply, and Add all change in sequence, three separate output values are sent to connected targets.

I'm not sure whether MIDI tempo information messages makes it through to the Faust node, but the tempo sync node is definitely the way to go. just build your Faust node with a absolute delay time parameter and then connect it to the tempo sync node - it automatically sends the correct time value matching the tempo and reacts to tempo changes etc.

upcoming docs:

Tempo Sync (control.tempo_sync)

Converts a musical tempo value to a duration in milliseconds and sends it as a modulation signal.
Tempo Sync converts a musical time value (such as 1/4 note or 1/8 triplet) to a duration in milliseconds based on the current DAW tempo. The output updates whenever the host tempo changes or any parameter is adjusted, making it suitable for driving time-based effects that need to lock to the beat.

The output is an unnormalised modulation signal carrying the raw millisecond value. If the target parameter expects a different unit (such as frequency in Hz), place a control.converter between this node and the target. When Enabled is set to Off, the node outputs the manual UnsyncedTime value instead, allowing a smooth fallback for standalone operation or manual control.

CPU: negligible, polyphonic.

Signal Path

Pseudo-code - hover highlighted terms for details // control.tempo_sync - musical time to milliseconds // BPM + parameters -> ms out (unnormalised) onParameterChange() { if Enabled: output = tempoToMs(bpm, Tempo) * Multiplier else: output = UnsyncedTime } onTempoChange(newBpm) { bpm = newBpm if Enabled: output = tempoToMs(bpm, Tempo) * Multiplier }

@Orvillain Nice work

@HISEnberg @Christoph-Hart I hit a problem with controlling a ScriptNode macro with a UI knob AND an envelope.

New post here: https://forum.hise.audio/topic/14793/control-scriptnode-from-ui-knob-and-envelope