Scripnode 101

ustk

@dustbro getSample is just a way to make an external function from the process one, nothing prevents you to remove it and make your algorithm directly in the process function, or make one getLeftSample and one getRightSample like below:

	float getLeftSample(float input)
	{
		return Math.tanh(input);
	}
	
	float getRightSample(float input)
	{
		return Math.tanh(input);
	}
	
	template <typename T> void process(T& data)
	{
		auto frame = data.toFrameData();
		    
		while(frame.next())
		{
			frame[0] = getLeftSample(frame[0]);
			frame[1] = getRightSample(frame[1]);
		}
	}

The only thing is that this way of using process to separate the channels actually transforms it in a frame processing. So if you want block processing of separated channels, I don't know the trick.

Dan Korneff

@ustk said in Scripnode 101:

if you want block processing of separated channels, I don't know the trick

Thanks again for this!
That's what I was doing, but got unexpected results. Now that I look a little closer, it appears that placing an SNEX node into a frame2_block returns a mono signal.

ustk

@dustbro Strange indeed...

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:

Screenshot 2022-02-01 at 13.12.55.png

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…

Scripnode 101

59

1.8k

10.4k

90.6k