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!

I'm actually moving into more JUCE C++ based projects now. But I've spent 18 years in music tech. Used to work for FXpansion, then ROLI, then inMusic until mid last year when I made the transition to developer. I've got a couple of HISE projects on the go right now - more synths and effects than sample libraries at the moment, but I've done sample libraries throughout my career, with a specific focus in drum libraries. I have a few Kontakt ports in the pipeline for this year too.

Eventually will launch my own plugin company as well. That is the goal.

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 I really like that UI. Very simple, accessible, and smooth looking - for lack of a better word!

@HISEnberg said in Third party HISE developers:

A bit abashed posting here with so much talent but here it goes!

Wouldn't worry about that, you've been very helpful in getting me up and running in various threads! So thanks! (and to everyone else also!)

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

I have a system where I have sidecar files next to each of my samplemap xml files. But then I've also turned my samplemaps into monolithic ch1 files. So my metadata (custom things like category, author, studio location, sound source, etc) gets picked up in the HISE standalone dev environment. But not inside the compiled plugin. Still trying to trace down why. But it strikes me that if I can avoid a sidecar file, and just embed the data directly into the sample map and the final ch1 file, then that would be desirable.

Thoughts?

@Christoph-Hart Lovely stuff! Thanks!

@DanH Not yet actually! Potentially another good reason to just build a custom panel.

@Christoph-Hart

		// Walk up to the top-level component to avoid clipping by
		// intermediate parent containers (e.g. panel areas).
		if(auto pp = parent->getParentComponent())
		{
			// Convert drag areas and label from parent-relative to top-level-relative coords
			auto topLevel = parent->getTopLevelComponent();
			auto parentOriginInTop = pp->getLocalPoint(topLevel, juce::Point<int>(0, 0)) * -1;

			dragAreas.offsetAll(parentOriginInTop.x, parentOriginInTop.y);
			
			if(!labelArea.isEmpty())
				labelArea.translate(parentOriginInTop.x, parentOriginInTop.y);

			topLevel->addAndMakeVisible(this, -1);
		}

For my usage, I had to change to the code above.

I think we need the Z-order to be dynamic. But I also think the parenting strategy needs to be dynamic. Either DirectParent, or TopLevel. How easy would that be to add?

DirectParent == current behaviour, where you want a container panel to clip the hover panel.
TopLevel == popup always floats about everything; probably correct for 99% of use cases.

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain There should probably be an option for either. There's also the labels to think about as well... It's not a one size fits all solution.

I just found another issue too - when you have your knobs inside a panel, that panel can easily clip off the floating popup for these depth knobs.... which is kind of annoying. Maybe the best solution for me actually IS to write a custom script panel that knows what knob we are hoving over, and assigns the depth knobs dynamically.

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain because my draggers (depth knobs) are always visible. All of them. So if I switch panels then the draggers still sit on top of the new panel. Make sense?

Yeah that makes sense. I think I might’ve been tempted to handle it a bit more locally rather than adjust the framework, it seems a bit sledgehammery to me, because I think the majority expected behaviour is that these mod depth knobs always sit on top of everything, and disappear when you move the mouse away. But that’s just my instinct. Interested to hear your thinking.

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain any panel that you want to appear at any point, let's say a floating mini preset menu, or a floating tooltip, or a page, the draggers will sit on top of. However mine are persistant, rather than appearing on hover, so that changed the dynamic a lot.

I don't get it. Why are those things related to drawModulationDragger/drawModulationDragBackground ??

@DanH said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain I found the scenario!!

I'm curious what it was ?

@Christoph-Hart Yes, that fixes it.

I did this:

pp->addAndMakeVisible(this, -1);

But I'm guessing the -1 isn't even necessary.

I'm honestly struggling to think of a scenario where you wouldn't want these depth knobs to always be on top of everything, to be honest!! But... if there is a need to support dynamic z-order assignments, then I'm a +1 to that!

@Christoph-Hart said in z-ordering issue when using drawModulationDragger/drawModulationDragBackground:

@Orvillain I think that was a custom request from @DanH - he was complaining that the mod draggers mask sibling components so I added some code that give them the same z-level as the knob that spawns it.

Check:

https://github.com/christophhart/HISE/blob/2b3d9bc0b3cb5817dcda1f5bd6366aba123531ab/hi_core/hi_core/MacroControlledComponents.cpp#L1280

If you remove the pIndex+1 parameter, the component is added at the bottom of the list with the highest z-order. Does that fix your problem? Let me know if it does, then I'll check where I can add this property so you can control it dynamically (and ideally per component).

haha, I literally just went digging through the code and found that line. Testing that fix locally. Will report back.