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

You can try to use the signalsmith CLI tool (or whatever they ship as a binary) to check your exact audio material. AFAIK I've not changed the internals of that engine too much instead of just wiring in IPP / VDSP and a few other small performance additions.

You can't expect parity with the sound quality of Elastique though. Rubberband sounds worse in my experience than signalsmith - v2 as well as v3.

There is also another timestretch library on the block - Bungee which has a pro version that claims to be on par with Elastique et al, so maybe that would be a contender.

HISE doesn't support MIDI 2.0

I'm living under a rock here. How wide is the DAW industry adoption of this? All of the hosts I'm using don't care at all about MIDI 2.0.

What limitations do you run into with the Midi Player?

It does in fact do a lot of heavy lifting to ensure sample accuracy so you would have to script a LOT to get its basic functionality up and running.

@Orvillain are nam files binary or json?

There‘s currently a gap in all non image or audio file resources (.hwt wavetables too eg), so this would be a good feature addition

@Lindon just like any other attribute. If you save it in a preset it will be restored in a preset.

AFAIK the sample loading is deferred until the plugin is initialised, so if you load a DAW project, it will not load the default preload size, then reload them again, but wait until everything is setup and then load the samples with the one preload size you set it to.

You probably might want to put that in a non-preset setting file somewhere.

@pelle afaik yes

@pelle you need to contact Pace for this. Everything in their SDK is proprietary, all I can say is:

• it's free to use if you just want to sign AAX plugins without iLok protection
• you need an iLok dongle to sign (alongside their other toolkits)
• once you get the SDK, you compile it, put it at the correct position in the HISE folder, compile the AAX version of your plugin, then sign it with the wraptool.