Scripnode 101

[Dan Korneff]

@ustk Looks like it's my code in processFrame. Lemme see if I can figure out the magic potion.

[ustk]

@dustbro That's what I'm doing, as you can see the output is stereo:

[Dan Korneff]

@ustk The framex_block gets it's stream from processFrame. If you leave that blank, the output will be unprocessed.

Here's the same example using an oscilloscope to see the results of placing the SNEX node into the frame block. I'm inverting one channel for easier viewing.

[ustk]

@dustbro Oh yes of course! My bad!!!

[ustk]

@dustbro Then you might not need a frame2_block, or?

[Dan Korneff]

@ustk Maybe, but without the frame2_block my DSP is glitchy and distorted.

[ustk]

@dustbro That kinda makes sense. I'm trying to get the channels in the processFrame with no luck. in fact it works for the left channel but not for the right one. I'm investigating the use of span with no more luck since yesterday...

[ustk]

@dustbro Got something! Try this:

	float getLeftSample(float input)
	{
		return input;
	}
	
	float getRightSample(float input)
	{
		return input * 0.05f;
	}
	
	// Process the signal here
	template <typename ProcessDataType> void process(ProcessDataType& data)
	{
	}
	
	// Process the signal as frame here
	template <int C> void processFrame(span<float, C>& data)
	{
		for (int i = 0; i<2; i++)
		{
			auto& s = data[i];
			
			s = i == 0 ? getLeftSample(s) : getRightSample(s);
		}
	}

[Dan Korneff]

@ustk Nice one! That's pretty close. Something about it is making the DSP process differently on each channel.

Trying my code again with just the process block seems to work now with:

	auto frame = data.toFrameData();

Since the data is being converted to frame data, I no longer need to use a frame?_block.

I can now pop it into a fix_block without glitches :)

[ustk]

@dustbro Glad it works :)
But strange the last solution with the processFrame isn't working properly...

[Dan Korneff]

@ustk said in Scripnode 101:

strange the last solution with the processFrame isn't working properly

agreed

[Dan Korneff]

@Christoph-Hart Are we able to embed compiled SNEX nodes within other wrapped DSP networks?
When I try to compile DPS that contains a compiled SNEX node within it, I get the following errors:

\dspnetworks\binaries\source\main.cpp(18): error C2065: 'Test_Node': undeclared identifier 
\dspnetworks\binaries\source\main.cpp(18): error C2672: 'scriptnode::dll::StaticLibraryHostFactory::registerNode': no matching overloaded function found

\dspnetworks\binaries\source\main.cpp(18): error C2974: 'scriptnode::dll::StaticLibraryHostFactory::registerNode': invalid template argument for 'T', type expected

[crd]

@dustbro I get the same errors.

[Dan Korneff]

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

@Christoph-Hart Just checking to see if this is still on your radar.

[crd]

Has anyone here had any success trying to compile a scriptFX with global mod node in the network? Details about what I am trying to do are here:
https://github.com/christophhart/scriptnode_testsuite/issues/5

I understand what Christoph is saying but there seems to be no way to disable global nodes from compiling.

Also, are there any actual performance gains to be had by compiling in this specific case??

[Matt_SF]

@crd You don' compile just nodes, you compile networks.
Regarding your problem, as Christoph suggested, try to create 2 separated scriptFX, the one with the global mod node (which won't be compiled) and the one with the Math.expr (which will be).

To enable/disable network compiling, click on this icon :

And simply allow the compilation of the 'math' network.
When you'll create the DLL, only this network will be compiled.

If you're using Math.expr nodes (and similar) you have to compile the network first before being able to compile your plugin.
But - AFAIK - there's no (real) performance gain to be had by compiling 'classic' networks, except maybe for real complicated ones.

[crd]

@Matt_SF Are the two scriptfx just for the purpose of creating the dll? I’m away from my rig st the moment but am sure the edit properties window is not giving the option to disallow compiling global mod nodes in a network.

The network isn’t complicated but does involve many nodes so maybe there are no performance gains to be had by doing this anyways…

[Matt_SF]

@crd no no, you must compile any network containing Math nodes in a dll in order to be able to compile your plugin. Otherwise HISE will throw an error while creating your plugin.

But since HISE can't compile global mod nodes into a dll, you have to split your network in 2 separated networks, disallow compilation of the network containing the global mod node and allow compilation of the one containing the math node.
(When we speak of 'networks' it means 'scriptFX' because 1 scriptFX = 1 network.)

So the math network will be embedded into the dll and the other will not. But when compiling your plugin, HISE will embed the dll and the other network directly into the plugin.

[crd]

@Matt_SF How does that help in the case of a network that needs a global mod node to interact with a math.expr node?

[crd]

This is what I see when I edit the properties of a global node:

It makes since to me that I would need to disallow these nodes from compiling into dll's but I do not see a way to do that. (but once again, I might just be spinning wheels here if there are no actual performance gains to be had by compiling these types of networks.)