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!

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.

Oh for n00b sake... I just call .changed() it would seem.

Could we get this extended to cover 20hz-24kHz ??? Unless I'm missing something, there doesn't seem to be a way to do it. I've been writing some custom Butterworth filters and evaluating them and diagnosing issues with cascading has proven a bit tricky in a few instances.

@dannytaurus said in Free-running, or randomised phase, for Waveform Generator oscillators?:

@Christoph-Hart Diving in to ScriptNode now. Fun stuff.

Quick question - if I want several random-phase oscillators, would I do this with multiple simple Scriptnode Sythns (like your snippet) in the Module Tree? Or would I create the whole multi-oscillator thing in one Scriptnode Synth?

I'm guessing both are valid approaches, but is there a benefit of one over the other?

Definitely recommend digging into Scriptnode and just playing around with it. Your best friends in this case are going to be the various container types. So if you wanted multiple random-phase oscillators, you could reproduce Christoph's example a couple of times over, using the split chain.

Could we get this extended to cover 20hz-24kHz ??? Unless I'm missing something, there doesn't seem to be a way to do it. I've been writing some custom Butterworth filters and evaluating them and diagnosing issues with cascading has proven a bit tricky in a few instances.

Has anyone run into this??

I have a project with some compiled networks. One of them is an LFO I built in scriptnode. It has a lot of functionality, but the basics are that I choose a sync mode either by switching between a source sawtooth generator, or a clock_ramp object that syncs to the host.

After that, I process the output to get the various shapes I want.

As a compiled modulator it works fine in polyphonic mode. But when I set it to monophonic mode, after a certain time it locks up and stops producing output.

I cannot confirm this with the non-compiled version (just loading in the scriptnode network)

@Christoph-Hart said in Dynamic reassignment of effect slots:

Just a small heads up that we have this now:

https://docs.hise.dev/tutorials/ui/index.html#draggable-fx-chain

As it turns out, that was reasonably easy to add.

I did a really crappy version of random phase, by writing a polyphonic c++ node that adds small amounts of delay to a voice every time a note is pressed. I'm not proud of it, but it might be something to consider.

Right so it looks like there's quite a few ways to potentially address this. But probably the most flexible is using the UserPresetHandler API:
https://docs.hise.dev/scripting/scripting-api/userpresethandler/index.html

This function seems extremely relevant:

UserPresetHandler.setUseCustomUserPresetModel(var loadCallback, var saveCallback, bool usePersistentObject)

It takes two functions - onPresetLoad and onPresetSave.

So in theory, I write a custom namespace for handling my custom preset format. It needs to be able to this kind of stuff:

• Gather all loaded samplemap names and any relevant identifiers
• Gather all parameters and their values
• Construct a sensible JSON array of all of the above
• Save it to a file on disk, using the FileSystem API coupled with the UserPresetHandler API.
• Use the onPresetLoad() method to reconstruct a selected preset in full.
• It also needs to be able to flag when sample content cannot be found.
• It needs to be able to also save and restore modulator states
• Any internal values for midi processors also need to be stored
• Arpeggiator patterns also
• Any routing matrix changes
• Maybe sample map details beyond names - root notes, velocity splits, etc?
• Add a version number to the file for future use
• UI states for selected tabs
• Provide some kind of sample relink method in situations where a samplemap or individual sample cannot be found
• For saving a preset, I should plan to allow custom meta-data to be added to a preset; things like author, style, type, etc...

Need to do some heavy thinking about this. Because the clients requirements are definitely quite a bit more expanded in scope than I initially thought.

@d-healey said in Custom browser - custom preset file format???:

@Orvillain said in Custom browser - custom preset file format???:

Any thoughts on this kind of thing

Sounds like a lot of work.

Yep it is! But they're paying for it....

@Orvillain said in Custom browser - custom preset file format???:

bundle the custom loaded .wav file, or the samplemap, with the preset.

What do you mean by bundle?

I'd probably settle for a preset file and accompanying .samples folder that sits next to it, with the preset file being updated to no longer include hard-paths, but relative ones instead. The enforcement being that the .samples folder HAS to live next to the preset file on disk.

I'm being asked about building a custom browser. They want to show a ton of meta-data for a preset or a sound (any individual samplemap). They want a ton of search functionality too.

They also want to be able to export a preset, and include any sample content with the preset - ie; bundle the custom loaded .wav file, or the samplemap, with the preset. For personal sharing purposes.

So RE: Browser. My first initial thought was to build a custom browser, with custom panels that paints columns and labels, and various visual widgets. These would all get populated from data parsed from JSON. Every samplemap would have an associated JSON file with the relevant meta-data next to it. On plugin load, this data is injested and stored in the main local database. Meaning when they add samplemaps down the line, the database can grow.

This would allow me to parse JSON according to their filter selections, and update panels, labels, paint routines. It's a good chunk of work, but I don't think it is particularly difficult.

The other requirement, of exporting a preset with its associated samples.... that feels likre I'm going to need a custom preset file format, to be able to store the actual names and guid's of sample-content. Which can later on be used to rebuild a sample map.

Any thoughts on this kind of thing?? I've only really just started thinking about the requirements here.

@d-healey said in What are you using to build UI for your plugin? What's your preferred way and why?:

Then I'll take that design and reconstruct it in HISE using look and feel.

Hey Dave. I'm in a similar situation right now, and the designers are soon going to be delivering Figma designs. Do you have any resources on how to best optimize this conversion process?

@Christoph-Hart said in What are you using to build UI for your plugin? What's your preferred way and why?:

In the long run I can imagine that the CSS renderer will be used more often for the UI elements that are suited towards this (!= sliders & knobs) as the declarative nature of CSS makes it faster to develop UIs.

I'm also interested in how far we can push the CSS renderer across the entire state of the plugin. Because in theory Figma spits out CSS code that we could use, which would speed up the UI development a lot.

@HISEnberg If in doubt, stalk @griffinboy

So following Chris's comment in that thread, it sounds like the node needs to inherit from:

public hise::TempoListener

And then you write a custom callback. Something like:

void tempoChanged(double newTempo) override
    {
        
        // yo bro, do a thing here innit fam bruv dudemeister
        for (auto& t : data)
	{
		t.bpm = newTempo;
		t.refresh();
	}
     }

But I haven't tried it yet.