Don't know if this is the done thing really, but I wanted to show off:
https://youtu.be/1kMHloRQLcM

Again, wasn't sure where to put this. But I created my own node.

https://youtu.be/-siB1UJfrD0

Modelled analog bucket brigade delay. I'm starting to build up quite a nice collection of delay and reverb utilities now!

@Chazrox I might do a video or two on everything I've learned!

@d-healey I really like that UI. Very simple, accessible, and smooth looking - for lack of a better word!

@HISEnberg
Yes I wrote a custom transient detector in a c++ node, and made sure it utilised an audio file, which I can load in my UI using the audio waveform floating tile.

I implemented spectral flux extraction:

• Take your audio.
• Perform an FFT on it.
• Extract the spectral flux envelope from the FFT.
• Downsample the spectral flux envelope (optional but can help accuracy)
• Perform peak picking on the spectral flux envelope.

I used the stock JUCE FFT processor.

Free mankini with every commercial license???

@Chazrox said in I wrote a reverb:

@Orvillain Please. I've been waiting for some dsp videos! I've been watching ADC's everyday on baby topics just to familiarize myself with the lingo and what nots. I think im ready to start diving in! There are some pretty wicked dsp guys in here for sure and I'd love to get some tutuorials for writing c++ nodes.

There's two guys who got me started in this. One is a dude called Geraint Luff aka SignalSmith. This is probably his most accessible video:
https://youtu.be/6ZK2Goiyotk

Then the other guy of course is Sean Costello of ValhallaDSP fame:
https://valhalladsp.com/2021/09/22/getting-started-with-reverb-design-part-2-the-foundations/
https://valhalladsp.com/2021/09/23/getting-started-with-reverb-design-part-3-online-resources/

In essence, here's the journey; assuming you know at least a little bit of C++

1. Learn how to create a ring buffer (aka my Ring Delay thread)
2. Learn how to create an all-pass filter using a ring buffer.
3. Understand how fractional delays work, and the various types of interpolation.
4. Learn how to manage feedback loops.

Loads of resources out there for sure!

Lesson 5 - SNEX code in a bit more detail.

So I'm by no means an expert in C or C++ - in fact I only just recently started learning it. But here's what I've sussed out in regards to the HISE template.... and template is exactly the right word, because the first line is:

template <int NV> struct audio_loader

Somewhere under the hood, HISE must be setup to send in an integer into any SNEX node, that integer corresponding to a voice. NV = new voice perhaps, or number of voices ????

The line above declares a template that takes this NV integer in, and creates a struct called audio_loader for each instance of NV. Indeed we can prove this by running the following code:

template <int NV> struct audio_loader
{
	SNEX_NODE(audio_loader);
	
	ExternalData data;
	double note = 0.0;
	
	// Initialise the processing specs here
	void prepare(PrepareSpecs ps)
	{

	}
	
	// Reset the processing pipeline here
	void reset()
	{
		
	}
	
	// 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)
	{

	}
	
	// Process the MIDI events here
	void handleHiseEvent(HiseEvent& e)
	{
		double note = e.getNoteNumber();
		Console.print(note);

	}
	
	// Use this function to setup the external data
	void setExternalData(const ExternalData& d, int index)
	{
		data = d;
	}
	
	// Set the parameters here
	template <int P> void setParameter(double v)
	{
		
	}
};

There are only three things happening here:

1. We set the ExternalData as in a previous post.
2. We establish a variable with the datatype of double called 'note' and we initialise it as 0.0. But this value will never hold because....
3. In the handleHiseEvent() method, we use e.getNoteNumber() and we assign this to the note variable. We then print the note variable out inside of the handleHiseEvent() method.

Now when we run this script, any time we play a midi note, the console will show us the note number that we pressed. This is even true if you play chords, or in a scenario where no note off events occur.

That's a long winded way of saying that a SNEX node is run for each active voice; at least when it is within a ScriptNode Synthesiser dsp network.

The next line in the script after the template is established is:

SNEX_NODE(audio_loader);

This is pretty straight forward. The text you pass here has to match the name of the script loaded inside your SNEX node - not the name of the SNEX node itself.

Here you can see my SNEX node is just called: snex_node.

But the script loaded into it is called audio_loader, and so the reference to SNEX_NODE inside the script has to also reference audio_loader.

@d-healey said in scriptAudioWaveForm and updating contents:

@Orvillain Did you try, AudioWaveform.set("processorId", value); ?

Yeah I did, and it does update it based on a follow up AudioWaveform.get('processorId') call - but the UI component doesn't seem to update, and still shows data from the previous processorId. When I compile the script, then the UI updates one time... but not on subsequent calls to the set method.

I figured I needed to call some kind of update() function after setting the processorId, but no such luck so far.

Start off with a tanh function.

Then put a high-pass filter before it. Set the range on the tanh to be quite high. 1-10 would do. Then tweak the high-pass cutoff and notice how it impacts the distortion.

Now add a low-pass filter after the tanh. Tweak the cutoff and notice how it cleans up the high frequencies.

Start from there.

That is a very weird one. Your snippet doesn't even have the matrix modulator that I can see. Removing the gain knobs matrixTargetId breaks the connection, but that is obviously not the fix.

@iamlamprey said in Building a replication of a piece of gear I have (.NAM):

@cemeterychips Altar has working NAM:

https://github.com/nytemairqt/altar

Check the DspNetworks/ThirdParty/amp.h file, it's using RTNeural & RTNeural-NAM

Edit: Sorry didn't realize you were new to HISE, this is definitely a bit more advanced of an implementation, I had to go this route because I couldn't get the NAM node working

Sorry, this might be a derail. But what were the fixes to HISE you made? Any reason they can't just be merged into develop?

@resonant said in How to detect and fix out-of-phase signals?:

@ustk @Orvillain ok I see.

Another one, is possible to detect pitch with fft in Hise without c++? I think this should be doable with Hise tools.

You'd be far better off getting something off the shelf and getting it into the scriptnode network. I'm not sure what is out there to be honest.

I'd approach this by using MIR principles to extract audio features across frequency bands, and then find alignment points within the feature matrix.

God I hate my stupid brain sometimes.

So yes... that is exactly what it was....

In my c++ I run these smoothers for some parameters. To avoid discontinuities when turning a parameter. You generally don't want to flush 1000's of parameter updates on things like delay times, so you smooth it out over time. Maybe only 10ms, but it helps to make it sound better and brings down CPU too. Cool.

And that was all well and good. Worked fine.

But in my setParameter callbacks, I was only setting the target. I wasn't setting the initial value. Which now I read it, is literally the dumbest stupidest mistake that I could've made.

Time for more Guinness.

@David-Healey said in How do I flush the UI parameters on first run??:

@Orvillain said in How do I flush the UI parameters on first run??:

So now I'm thinking, maybe this is a custom C++ code or script node problem.

Could be...

ooooo... looks like it might be any of my effects that uses my ExpSmoothedFloat class to smooth the incoming parameter changes!

I've genuinely been slamming my head against this for the past 4 hours.... and it was nothing to do with the UI side after all... at least it seems like.

hmmm... no that didn't seem to work either.

Now, I might've been being dumb all along... but on a hunch, I tried a different effect.... and it seems like at least some of those parameters DO flush on init correctly... and some of them don't.

So now I'm thinking, maybe this is a custom C++ code or script node problem.

@David-Healey said in How do I flush the UI parameters on first run??:

Ok, what about using a timer that is started at the end of the callback, and in the timer you call .changed()

I'll give it a go!

@David-Healey said in How do I flush the UI parameters on first run??:

@Orvillain Are you calling .changed() from the menu's callback?

Yeah I am, there's no other callback to use right now.

@David-Healey said in How do I flush the UI parameters on first run??:

What happens if after this stage you call .changed for each of those components?

I get this in the Console:

Interface: Skipping changed() callback during onInit for grf_FXEngine1_FX1_Graph1
Interface: Skipping changed() callback during onInit for btn_FXEngine1_FX1_Sw1
Interface: Skipping changed() callback during onInit for menu_FXEngine1_FX1_Menu1
Interface: Skipping changed() callback during onInit for btn_FXEngine1_FX1_Sw2
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param1
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param2
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param3
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param4
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param5
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param6
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param7
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param8
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param9
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param10
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param11
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param12
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param13
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param14
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param15
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param16
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param1
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param2
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param3
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param4
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param5
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param6
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param7
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param8
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param9
Interface: Skipping changed() callback during onInit for knb_FXEngine1_FX1_Param10