@d-healey Yah I'm assuming that must be the case. I'm going to try a fresh pull and build.

@ulrik said in Clone ScriptNode - getting a simpel value passed in...

Thanks Ulrik, how did I miss that?

LMP

@Christoph-Hart The plotter looks very rough... Are we able to get a better resolution?
It even looks like the resolution is not the only problem but the path construction itself... a stride value not optimised?

Screenshot 2025-11-10 at 13.37.27.png

@dannytaurus

Multiple wavetable synths will use a lot of memory.
Christoph's WT engine creates mipmaps (multiple antialiased copies of the wavetable).
If you have multiple WTs loaded into separate WT engines simultaneously, each one will have multiple copies of the wavetable.

However, this memory is probably still small compared to say, a regular multisampler... However 100 wavetables is gonna get big I can imagine you could pass the GB mark of ram usage.

Can't speak for cpu, you can try it but I'd assume cpu is okay as long as you don't have the inactive synths do any processing when silent.

If you are trying to acheive clickless swapping or something (idk if the WT engine does this already? Or what your goal is with having multiple WT engines - fast loading maybe??? No silence dropout???)
You could just have two WT engines, keep one silent, and use the silent one to load the new wavetable, once ready, volume fade between them. Then you get a seamless handover to a new engine.

@Taihongcraft But the node within a soft bypass node

@ustk aaahhhh here you go! haha. I gotta see this...brb.

@Rognvald You can put it all in the interface MIDI processor if you want to keep things simple - just avoid doing any UI stuff in the MIDI callbacks.

// This sort of thing should be avoided in a non-deferred script. Buttons[index].setValue(true); Buttons[index].changed();

However the ideal situation is you separate UI logic from MIDI processing by using separate processors for individual tasks.

You can add the velocity code I described above alongside your current script.

Those reg variables you have should most likely be const. Rule of thumb is if the values are fixed (or it's an array or object) use a const. If the value is going to be dynamic then use a reg.

@iamlamprey Looks like the value is being normalized somewhere.

@ustk
Thanks for your help. I set the AllowCompilation flag in the DSP Network’s properties, compiled the network, and exported the DLL. The effect now works — but I’m still getting the prompt:
“You don’t need to wrap the root node. Just tick the AllowCompilation flag in the properties, save this network and export the DLL.”

Do you know why the prompt keeps appearing even after I’ve done that?
I appreciate any guidance.
Thanks again!

Best,

Capture d'écran 2025-11-08 013223.png Capture d'écran 2025-11-08 014654.png Capture d'écran 2025-11-08 175324.png

@ustk Awesome! 😂

@Dan-Korneff Did the same, seems robust enough 👍

@ustk Thanks for the pointer. I added another commit other than the PR to ensure the new props are shown in the Data section of the UI.

@Lindon I havent gotten that one much before. I get whats happening now. 🙏

@Oli-Ullmann By "free-running" I mean not reset on NoteOn events. And yeah, I found the IgnoreNoteOn parameter right after my last post 😂

Thanks anyway! 🙌

@d-healey
Yes, that's right! Thanks for the tip! :-)

@Orvillain Have you enabled the global app data folder on MacOS in project preferences?

@d-healey thanks. I ended up going back to Globals and FixObjectArrays as Im actually using values all over the place...., it makes me shiver a bit but hey .....

@d-healey yeah