@HISEnberg yup that should fix it - it fixes the webview tutorial on my system, but it's just a hack - I had to delay the webview initialisation in FL. Let me know if it persists in your project.

KVR is the 4chan of music forums, don‘t bother…

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
}

@HISEnberg this. The structure of the shape FX module is somewhat limited and you can easily create whatever wave shaper + signal flow you want in scriptnode and if you compile it down to C++ it's about as efficient as the inbuilt wave shaper.

@David-Healey it counts the number of quotation marks in the text before. if even => add two. there must be some quote char messing up this logic in your code.

@nohasm191 haha yes we all do human things as humans. Because we are human and not a robot.

@Oli-Ullmann what are you trying to achieve? Not sure if a webview is the solution.

I could reproduce the crash - unfortunately I couldn't solve it properly, so the only fix is to delay the initialization for Webviews on FL Studio if the plugin is opened. If I "double click" on the instrument track, it crashes in the FL code, not the destructor of the webview (which I hoped it would).

I'll push the fix tomorrow.

@ustk on macOS JUCE6 is already using the native CoreGraphics API which then uses whatever is fastest. Plus you can attach OpenGL, then it will use this for rendering primitives.

You can already switch to JUCE8 and try it the performance gets better. Ask Claude to reenable Direct2D then as I had to disable it to remain consistent with the UI performance of JUCE6 - I discovered some things to get much faster, but some things to get much much more slower, so I decided to disable it by default in the custom JUCE8 branch as this introduces too much of a moving target.

in a timer callback to create an animation - the user interface quickly becomes very laggy if the panel is somewhat large. The Cubase interface also becomes very laggy.

Use this to deactivate animation timers if multiple instances start clogging up the UI thread:

https://docs.hise.dev/scripting/scripting-api/content/index.html#setsuspendtimercallback

Juce6 uses CPU instead of GPU, one of the main reason I am waiting for the full Juce8 implementation.

Where do you get that information? JUCE8 is using the same Graphics renderer, it just adds a Direct2D renderer that might or might not be faster on Windows depending on your projects (HISE itself eg. was super slow when I enabled it).

If JUCE8 would be a revelation in solving UI performance I would have made the jump years ago, but it's more or less the same.

@David-Healey nope, won't work.

What if you actually create the network dynamically?

// define this somewhere in your interface script
global NUM_CHANNELS = 8;

// Put this code in a Script FX that is set to use the number of channels
const var dsp = Engine.createDspNetwork("mixer");

const var mixer = dsp.get("mixer");
const var multi = dsp.createAndAdd("container.multi", "multi", "mixer");

for(i = 0; i < (NUM_CHANNELS/2); i++)
{
	// create a gain module
	var g = dsp.createAndAdd("core.gain", "gain" + (i+1), multi);
	
	// fetch the gain parameter
	var dst = g.getOrCreateParameter("Gain");
	
	// create a root parameter
	var src = mixer.getOrCreateParameter({
	    "ID": "Gain" + (i+1),
	    "mode": "Decibel"
	});
	
	// connect the two
	dst.addConnectionFrom({ID: "mixer", "ParameterId": "Gain" + (i+1)});
	
	// copy the range to the source parameter
	// (make the warning icon disappear...)
	src.setRangeFromObject(dst.getRangeObject());
}

@David-Healey ah ok. BTW are you sure you need to compile them? If you're just using a simple multi channel DSP network with multiple gain modules in a container.multi container, then the DSP overhead is negligible - definitely lower than the old scripting approach.

@David-Healey but with rhapsody you cannot pull in compiled effects anyway unless you embed them in the player binary - that's the one hard restriction that comes with the full player expansion system.

@David-Healey what's the effect? just a mixer?

If you use it in different projects we might solve this by allowing FixChannelAmount to be a preprocessor, then it can pull in the actual channel count from the project it compiles the DLL too? So if Project A needs 6 channels, but Project B needs 16, you can just enter NUM_PLUGIN_CHANNELS (or whatever preprocessor you define) and it should cleanly pass that through to the C++ code generator.

@David-Healey Oh good spotting, this might come from the fact that there's some internal path normalization but the wildcards do not use this.

BTW, I've added another feature to the asset manager last week: you can define a SharedWildcard which allows you to define files that might be shared across multiple of your assets - the asset installer will then skip them at installation / deinstallation (and verifies that they don't conflict when installing two assets that share files).

@Morphoice currently multichannel layouts are all set to use stereo pairs as output, but I'm working on a project that might require certain multichannel configurations soon so it's on the roadmap.

But AFAIK that's just cosmetics and most DAWs can just reinterpret the channels with a given channel layout. As far as internal processing goes, you can definitely calculate these with Faust DSP, just enable multichannel processing in the Script FX that hosts the network.

@David-Healey Yes that is the case - the optimization possibilities that come from assuming a fixed channel were too tempting.

IIRC Faust also assumes some kind of known channel set, no?

@David-Healey I met with Tobias last week and we discussed improving the integration with Moonbase. I'll be working on a "native" module that integrates with HISE nicely without having to go to JUCE8, but I'm currently swamped with other stuff to do.