Scripnode 101

[Dan Korneff]

@crd said in Scripnode 101:

wrap the node before you compile it

Did you say "wrap" or "crash"? Cause I can get ONE of those to happen :beaming_face_with_smiling_eyes: :beaming_face_with_smiling_eyes:

[crd]

@dustbro ha :) sorry that does seem like the right steps.

[Dan Korneff]

Through trial and error, I'm able to wrap a node in HISE by closing and reopening between each step.

[Dan Korneff]

This post is deleted!

[Dan Korneff]

now when I compile the dsp network, I get these errors in VS2017:

1>c:\users\dan\desktop\wrap 3\dspnetworks\binaries\source\chain.h(38): error C2923: 'scriptnode::container::chain': 'NV' is not a valid template type argument for parameter 'ParameterClass' (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\desktop\wrap 3\dspnetworks\binaries\source\chain.h(35): note: see declaration of 'NV' (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\desktop\wrap 3\dspnetworks\binaries\source\chain.h(36): error C2955: 'scriptnode::container::chain': use of class template requires template argument list (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\documents\github\hise\hi_dsp_library\node_api\nodes\container_chain.h(127): note: see declaration of 'scriptnode::container::chain' (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\desktop\wrap 3\dspnetworks\binaries\source\chain.h(43): error C2955: 'scriptnode::container::chain': use of class template requires template argument list (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\documents\github\hise\hi_dsp_library\node_api\nodes\container_chain.h(127): note: see declaration of 'scriptnode::container::chain' (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\desktop\wrap 3\dspnetworks\binaries\source\dspnetwork.h(23): error C2923: 'scriptnode::container::chain': 'NV' is not a valid template type argument for parameter 'ParameterClass' (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\desktop\wrap 3\dspnetworks\binaries\source\dspnetwork.h(20): note: see declaration of 'NV' (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\desktop\wrap 3\dspnetworks\binaries\source\dspnetwork.h(21): error C2955: 'scriptnode::container::chain': use of class template requires template argument list (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\documents\github\hise\hi_dsp_library\node_api\nodes\container_chain.h(127): note: see declaration of 'scriptnode::container::chain' (compiling source file ..\..\Source\Main.cpp)
1>c:\users\dan\desktop\wrap 3\dspnetworks\binaries\source\dspnetwork.h(28): error C2955: 'scriptnode::container::chain': use of class template requires template argument list (compiling source file ..\..\Source\Main.cpp)

[Dan Korneff]

Me trying to figure out scriptnode...

[ustk]

@dustbro said in Scripnode 101:

I guess a more direct question is: how do I bypass the oversampling from the Main Interface...

Back before the new scriptnode version, we could just connect a parameter to the bypass button so it was easy for all kinds of nodes to control the bypass.
Now, this is not possible anymore, but I don't know if it is intentional from @Christoph-Hart removing this ability. So if it has been lost during the migration then it might be re-implement, or perhaps with another way to access it...

@iamlamprey Doubling the nodes is not an option. Imagine if you want a selector with x2, x4, x8...

[Christoph Hart]

@ustk Yes this is intentional. The reason is that if you want to bypass nodes, you usually want this process to be click free (like the container.soft_bypass node offers now). But having the overhead of the "bypass smoothing" for every node wastes too much performance.

Now the oversample node is maybe the only node where you still want to connect the bypass in order to change the oversampling (I can't think of a use case where it makes sense to eg. bypass a fix_block node). However I would rather add a dynamic oversample node that exposes the oversampling factor as parameter that can be modulated like any other knob. This will also solve the problem of having to duplicate your signal chain in multiple oversample containers like you described

Doubling the nodes is not an option. Imagine if you want a selector with x2, x4, x8...

[ustk]

@christoph-hart said in Scripnode 101:

However I would rather add a dynamic oversample node that exposes the oversampling factor as parameter that can be modulated like any other knob.

That would be nice indeed

[Dan Korneff]

@christoph-hart That would be excellent.
related to oversampling:
After doing some tests, I'm finding that the send/receive nodes don't play nice with oversampling. Most of the time they show a samplerate mismatch error. This also happens with setMinimumSampleRate. Using that in conjunction with a dsp network that contains those nodes produces no output (probably because of the mismatch).

[A Former User]

@d-healey said in Scripnode 101:

@dustbro Click "onInit" and start adding components. You shouldn't use the interface designer for scripts that aren't the main interface, you should do it through scripting.

Ok... Why is that?

[d.healey]

@ursbollhalder When you save your project as an xml an xml file is also created for all of the components on your main interface, but no such file is created for secondary scripts.

This means that if you copy your script from one project to another it won't have any components on the UI, so you'd have to create them again. If you add the components inside the script then you can share that script with other projects or with other people and the UI will also be recreated automatically each time.

If you look at my modules on github you'll see they all define their own interface so that they can be dropped into any project and everything will should work.

[A Former User]

@d-healey Yeah! I see... I actually ran into that problem when creating a granular and a custom arp script processor with an interface. I thought it to be a great idea, creating these modules for reusability! But yeah, the next time I imported them in another project it was a mess! I then created a secondary js-file for them, in which I put all the Content.setPropertiesFromJSON for every element. Because also your knob modes (linear, decibel, etc.), as well as min and max values do not get saved without the xml!

[crd]

This post is deleted!

[A Former User]

So the modchain does not have an audible output signal, right?

[Christoph Hart]

@ursbollhalder Yes. It's supposed to be used with a peak node at the end so beyond that point the signal should not matter anymore.

[A Former User]

@christoph-hart Yep... That's what I messed up... I put a simple xfader into a modchain (doesn't make much sense, I know) and had that in a split container and was wondering where the signal was coming from! Oh my !

[A Former User]

@christoph-hart If I mix between a dry and a wet signal with an xfader, is it correct to use the overlap or rms mode to avoid a drop in volume when adjusting the mix slider on top? https://docs.hise.audio/scriptnode/101/drywet.html note to self: RTFM!

And as the last question... can I somehow dynamically load convolution files into my scriptnode house of wonder?!? Similar as to when I load those files into the standard HISE convolution module with a combobox f.e.?!

I have 3 convo containers that filter the incoming signal... etc. It would be nice if I could let the user make those choices in a combobox... see here:

https://drive.google.com/file/d/1GnAKZopF74ACH3vg8omvBH1xq6S-DkNA/view?usp=sharing

[A Former User]

So I added a couple of knobs to my scriptFx, as instructed above by @Christoph-Hart...

Now when I add f.e.

const var myKnob = Content.addKnob("myKnob", 30, 20);

and then later on take that line out and recompile, the knob and some xml-graveyard junk is still in there somehow! Also not sure where the xml for the scriptFx-interface would be, so I could frankenstein my way through this for now...

[A Former User]

And here's to my very last question of today:

Is there a reason not to forward the params to the UI but first creating intermediary one on the scriptFX ui? I could think of re-usabilty issues... but what else?!