@zachhealy1005 Explain what you've tried step by step or show me a video so I can see where the problem is happening.

@Felix-W said in The Legato between samplers:

will point KS to the legato Sampler

I don't understand what this means

@Bart Aha I figured it out (watched a YouTube tutorial).

I'm able to load/unload the instrument multiple times without any issue.

Which OS are you using?
Which version of FL Studio?
Which CPU?
Are you testing in a new empty project?

I've updated the Rhapsody build with a couple of tweaks, let me know if that improves the crashing issue.

https://e.pcloud.link/publink/show?code=XZt75cZ38LCNl1BtXVrWXQ3s1xTDH4vfpLV

@Lindon Here's the fix, just two lines need changing:

https://github.com/christophhart/HISE/pull/983

It is related the default state being saved when loading the first expansion.

@David-Healey
I'll do that tomorrow and get back to you then. :-)

@observantsound I think the HISE CLI will one day handle this: https://github.com/christophhart/hise-cli . So you can point an AI agent at HISE and have it build the module tree.

Likewise, you can crack open the .xml and copy/paste whatever is happening with one sampler to all the others, but you will need to update the names and everything. You can also just let an AI do that (but it can become problematic if it becomes corrupted).

I believe your intuition was correct though, using the builder is meant to solve this but it is buggy atm.

It can become tedious work though, a copy/paste feature for the module tree would be a nice addition.

There is a detailed comparison of various pitch algorithms.
Rubberband performs really well and it's not too difficult to integrate into Hise.
I think there's even a detailed post somewhere here on the forum about this topic.

@pgroslou Even the Lite models of the previous version, which consume less CPU, don't work; only the standard models work.

Hopefully, the A2 NAM (which has two versions depending on CPU usage) will be integrated without any problems.

@DanH said in Matrix modulation connection is broken in exported plugin:

He can drop that
addModuleStateToUserPreset call unless he needs the container's own chain
state in presets.

Yep I need it, so I can't remove it, then 2 MatrixData blocks it is and will be...

Two root-level blocks means two live ScriptModulationMatrix instances at save
time. Unlike most Engine.createX calls there's no caching — each call to
Engine.createModulationMatrix() constructs a fresh object and registers a
fresh state manager, even for the same container ID. So ustk should search his
scripts for a second call (a second script processor, an included file, or a
call inside a function that runs more than once). Restore-side it's mostly
benign (each manager restores from the first MatrixData child via
getChildWithName), but it's the smoking gun that two matrix objects are alive
— and two objects both performing remove-all/re-add restores on the same tree
is exactly the kind of thing that could leave the runtime side confused.

Nope, no smoking gun here.

The signal path goes stale if:

the container's child modulators get rebuilt after the matrix restore
(remember MatrixData restores last, but postPresetLoad, sample preloading →
prepareToPlay, or anything his preset postCallback does runs after that),

something worth investigating, especially prepareToPlay that has been modified recently to fix another matrix bug...

Practical suggestions for ustk

Grep the project for createModulationMatrix — ensure exactly one call, in
onInit, stored in one const var. If duplicates persist in fresh saves after
that, an old instance is being kept alive.

Always had only one here

Drop addModuleStateToUserPreset("Global Modulator Container").

Nope, need it for what it does. And anyway I tried without and it doesn't seem related to the issue.

Check whether the broken targets' source modulators are bypassed/disabled
at the moment the preset finishes loading (the active-list trap above).

Nothing's bypassed

Note whether broken targets are MatrixModulators in mod chains vs.
script-slider parameter targets — they use different listener paths
(MatrixModulator::onMatrixChange vs MatrixCableConnection), which would narrow
it to one code path for a proper bug report to Christoph.

Only MatrixModulators in mod chains here, not direct parameter modulation

@ustk Ok I think im understanding. Thank you.

@Christoph-Hart I'm also still encountering this issue.
I've also tried all kinds of formats
"{PROJECT_FOLDER}/Scripts/test.js"
"{PROJECT_FOLDER}/Scripts/ScriptProcessors/test.js"
"{PROJECT_FOLDER}/test.js"

I also get onControl cannot be parsed.
My test.js is a file I saved after adding a blank script processor to my container.

1:
"Right-click/connect to external script": Works!
"Rick-click/reload connected script": Works!

2:
Adding script via Builder.connecttoScript: On Control cannot be parsed.
"Rick-click/reload connected script": Does not work "because connected script is not a valid HISE script. OnControl( cannot be parsed"

function onVoiceStart(voiceIndex) { "Hallo"; } function onVoiceStop(voiceIndex) { } function onController() { } function onControl(number, value) { }

@Sampletekk David, I bow in your general direction!

@David-Healey 👍

@resonant It's optional, HISE will fallback to a less efficient algorithm that's all.

Hi all, good to be here :-) I'm the developer of StripKit, glad you like it. If you guys have any features you'd like to see or any bugs you'd like to report for me to fix, please feel free to contact me here or shoot us an e-mail.

@David-Healey This worked thank you

@svkpowa Aha ok, just took a look at it and it's probably not needed for new projects.

@David-Healey Very excellent wares they are too 🙌

@dannytaurus absolutely 👍

@HISEnberg @David-Healey Yup that works! I get it now. I've been compiling like a mad man lol